[ofEditMesh3dVertex] should update the array and screen at the same time. I just tried it's help file and as you said, it didn't work as expected. So it should be a bug. I will fix this as soon as possible and upload the new version. (hopefully by the end of this week)
Thank you for finding and reporting the bug.

EDIT : I fixed the bug which applies to all mesh2d/3d editor objects. I will update and upload the new version as soon as I also fix a few other bugs. (I'm currently trying to fix the orientation problem which light, camera and viewport objects have)
Also, I will add the GUI abstractions in the new version.

int numVerts = mesh.getNumVertices();
for (int i=0; i<numVerts; ++i) {
ofVec3f vert = mesh.getVertex(i);
float time = ofGetElapsedTimef();
float timeScale = 5.0;
float displacementScale = 0.75;
ofVec3f timeOffsets = offsets[i];
vert.x += (ofSignedNoise(timetimeScale+timeOffsets.x)) * displacementScale;
vert.y += (ofSignedNoise(timetimeScale+timeOffsets.y)) * displacementScale;
vert.z += (ofSignedNoise(time*timeScale+timeOffsets.z)) * displacementScale;
mesh.setVertex(i, vert);

looking forward for the update, especially for the gui abstractions (which could solve some of the problems i had with the classic pd gui).

If you want to see how "fill" message can be used with loader object, please take a look at ofelia/examples/drawing/lineNoise.pd example.

Writing large number of arrays to mesh every frame can cause slow down. However, I will optimize the code of loader objects for path, polyline and mesh in the close future. I have an idea to simplify and improve the internal process for these objects.

But still, it will not be as fast as the compiled openFrameworks code which is the downside of realtime programming environment like Pd. But I'd say ofelia can run much faster than Processing at least based on my testing.

If you want to use "fill" to modify the vertices stored in a mesh, you should use [ofGetMesh3dVertex] to get the vertex at the specified index.
And then you can modify the vertex (e.g. add random values to it) and send "fill vertex x y z index" message to [ofLoadMesh3d] object. (it can also be like "fill vertex x y z first last" if you want to fill the range(first, last))

Here's the patch which I added what I explained above. hubble11.pd

You will find this part in the patch.

[ofCountUntil] is like [until] and [ofCount] merged together so you can use it instead of using the 2 objects.
I hope this will help.

[ofEditMesh3dVertex] has same functionality as [ofEditVec3f] because mesh3d's vertices are made of vec3f data type. These editor objects can be useful for handling properties of 2d/3d object such as position, velocity or acceleration.

You can read the OF documentation about this. http://openframeworks.cc/documentation/math/ofVec3f/
Also, you can check examples from ofelia/examples/vectors directory.

I fixed your patch a bit so it doesn't have to use [delay] anymore.
I also wrote some note about how things work at the top of the patch.

I guess you may have done something wrong with [ofMap]. It doesn't automatically clamp a value between the range so you need to use [ofClamp] or [clip] to clip the mapped value. But I think I will add the 5th optional argument to [ofMap] which can enable/disable the clamp since the OF method also has it. http://openframeworks.cc/documentation/math/ofMath/#!show_ofMap

I think I will quickly add this update to the current version(v1.0.6) today or tomorrow.

Also, you may have been confused when implementing "ofGetElapsedTimef()" in OF which returns the elapsed time in seconds but [ofGetElapsedTime] object in ofelia actually returns the time in milliseconds. So I had to divide the value by 1000 in ofelia.

Since I find this can be confusing to some users (especially ones who used OF), I'm considering to make [ofGetElapsedTime] return the time in seconds and create another object called [ofGetElapsedTimeMillis] to return the time in milliseconds similar to the original OF methods http://openframeworks.cc/documentation/utils/ofUtils/#show_ofGetElapsedTimef

I wonder what you think about this idea.

And If you still have trouble implementing magnifying example in spite of knowing the possible issues I mentioned above, please let me know.

EDIT: I just updated and re-uploaded v1.0.6 onto Deken after applying the above mentioned things. Check out ofelia/CHANGES.txt file for changes.

And here's an updated patch for v1.0.6 hubble13a3.pd this one no longer divides [ofGetElapsedTime] by 1000 because [ofGetElapsedTime] now returns time in seconds.

thanks!