I started to realize this Open Frameworks tutorial with Pure Data and Ofelia: http://openframeworks.cc/ofBook/chapters/generativemesh.html
Everything works fine until i reached the chapter "Manipulations: Adding effects that modify the mesh". Theres no need for me to finish the tutorial, but perhaps someone wants to use the patch, or optimize it, or learn from it. Perhaps I will finish the tutorial by myself when I have the time and know how to do it.
hubble.zip

@cuinjune hi. i have a question regarding ofEditMesh3dVertex. if i edit an array element it gets updated, but not on the screen, only if I recreate the ofWindow object the screen gets updated (also the case with the help file). Is there another way to make the change of the vertex position visible? ofEditPolyline3dPoint for example does work like i expected it from ofEditMesh3dVertex and updates immediately.

@Jona Hey, really well done! You learn so quickly.
Can I include your hubble patch in the ofelia "example/3d" folder for the upcoming update? I think it will be helpful to other users.

[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.

@cuinjune of course you can include the patch, but its not yet exactly the same as described in the tutorial. i will try to optimize it / make it the same and update it. thanks a lot for fixing the bug(s). do you know the most efficient way to change the position of all vertices of a mesh at "once" but with individual values? in the sequencer patch with a max of 128 vertices it was no problem, but with 2000 vertices or more like in this patch there is a heavy cpu load if i change them the same way.
in the tutorial they do it like that but i had problems translating the code to pure data:

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).

@Jona Hi, Thanks. It doesn't have to be same as the tutorial.
Could you please upload the patch so I can try changing the number of vertices?

@cuinjune alright. i edited my question above, because it wasnt obvious. i tried to change the positions of all the vertices and not the number of vertices. will send you the patch tonight.

@Jona If you have a fixed number of vertices and you just want to replace the values of array elements, the fastest solution would be sending "fill" message to [ofLoadMesh3d] object or using [ofEditMesh3d] object. (which will work fine in the upcoming version)

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.

@cuinjune thanks for the explanations. here is an updated version. motion works nice now with ofEditMesh3d. "fill" seems great in the LineNoise example with ofGetPolyline2dCommand, but in my patch with ofGetMesh3dCommands (inside the orange canvas) it is somehow much slower than ofEditMesh3d. perhaps it is because i use ofGetMesh3dCommands because there is no ofGetMesh3dCommand?
hubble10.pd

@Jona [ofGetMesh3dCommands] outputs all stored mesh commands as a list. It's mainly used for copying one mesh to another and printing out a large number of list to pd console can be really slow.

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.

@cuinjune thanks a lot, this is great this way "fill" makes the patch much more efficient, i have around 5% cpu load now. are there cases where it is better to use ofEditMesh3dVertex instead? hubble13.pd

@Jona Technically, you can do everything that [ofEditMesh3dVertex] can do using [ofGetMesh3dVertex] and "fill". But if you use [ofEditMesh3dVertex], you can directly apply various math operations to its internal data which can be more convenient(and sometimes more efficient) than having to use [ofGetMesh3dVertex], [ofExpr] and "fill".

[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.

@cuinjune i tried to patch the last two parts of the tutorial orbit and magnifying, it works more or less but i think i choose wrong values for ofMap or ofNormalize, or i made something wrong with orientation. hubble_13a.zip

Hi man, I implemented the orbit part. Here's the patch. 1521650739907-hubble_13a2.zip

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.

@cuinjune hi. Thanks for your work (and the hints), especially for the update (with the very nice gui examples) and ofelia itself I really like it. I think it is a great idea to make objects with the same functionality as in open frameworks, I would be interested to know what others think about that. I am without a computer until sunday, so I will check the patch then. If you want to use it for the examples feel free to change / use what you want (like with any other patch). For me this patch is mainly for learning purposes.

@cuinjune i think also magnifying works well now, also together with orbit. its also a 3dmesh again. hubble13a7.pd

Hi everyone,
i'm just starting to coding in ofelia PD. In general the external library work very well...but now that I download your patches there are son much objects that Pd could not create.
Anyone could explain me how can I use these object?
here the screenshot

thanks!

This thread is quite old, and AFAIK, @cuinjune has sort of rewrote the library and now there's only the [ofelia] external, and everything else is either written as a Lua script and loaded to [ofelia], or an abstraction, that includes [ofelia] with a Lua script loaded to it, pretty much the same thing, only the abstraction simplifies things a bit.
The best way to go would probably be to learn more about openFrameworks and Lua. This way you can really unleash the power of Ofelia!