Leaderboard

THis looks a lot like what Blender has...easy to set up and fast. I own Xparticles, but I'd welcome anything in Cinema 4d that is easy like Blender's fluids.

Just wondering if there is any value to this strategy for using and staying current over the long term - especially if you have R23 perpetual. as R23 was a pretty good release, especially in the area of cross platform integration and animation. Purchase and keep current with Redshift, Octane and/or whatever 3rd party renderer you prefer. Really, from a "features" perspective, rendering improvements usually deliver the biggest gains to most users. For me, I love Redshift and its upgrade costs are only $250/year. Use Substance Designer for all your texturing and mapping needs. Indie license is $240/year. I am now at $490/year total. Also, Redshift can read .sbsar files so those two play together. Should you need a new feature with the latest version of C4D, then purchase the monthly subscription (billed monthly) for the latest version. You could do that for 9 months out of 12 and still be ahead of the annual perpetual license upgrade cost. When you have what you need, export it to FBX and alembic to bring it back into R23. As I am already into this for $490, I could do the monthly plan for 4 months out of the year and still be ahead of the perpetual license upgrade cost. So with that mindset, what have you really lost? True, there are some convenience issues you have to deal working with multiple apps but you actually end up with better tools like Substance Painter, Substance Source, Substance Alchemist and Redshift - resorting only to the latest version of C4D for a brief period of time should you need a new tool -- and you bake out the result for importation back into R23. Of course, this is all so we can stick with the interface and stability we love the most. You could always follow a fourth option: Chuck it all, bite the bullet and live with a quirky interface and use Blender. Just a thought. Dave

Everything between a StartUndo and EndUndo is a single undo (to the user). You can do as many AddUndo as you want, on a same or different object. To the user it is still a single undo operation. However, if you do a StartUndo-AddUndo-EndUndo for every of your 200 tags, then yes: the user will get 200 undo entries. But StartUndo-AddUndo-AddUndo-AddUndo-...-EndUndo is just a single undo operation.

I have adjusted the Python script, as I noticed I performed an undo on the host object, instead of the tag itself. You will need to do the same in your C++ code.

I am with you on preferring C++ over Python, but I cannot deny that Python is much easier to prototype a plugin. However, for debugging purposes or finding a problem in code I much prefer having a C++ plugin at hand. If I may I would like to point out some issues in your code. 1. In your CommandData::Execute you call "doc->StartUndo()" before obtaining the object you will be working with. This means that -potentially- the obtained object is nullptr and you exit the method. But without closing the started undo. Better to start the undo after having obtained the object. In your case you could even move all the undo stuff into your "RemoveTagsFromLeft" method, encapsulating the for loop. 2. AddUndo always need to be called BEFORE you actually perform the action, except when adding new objects. See the AddUndo documentation To get selected object(s) see BaseDocument::GetActiveObject and BaseDocument::GetActiveObjects To debug: right mouse click your project in Visual Studio, and select "properties" at the bottom of the popup-menu: Enter the location of the cinema4d executable. Optionally you can provide a "g_alloc=Debug" argument, which will provide allocation issues like memory leaks, etc. You can use "ApplicationOutput" to write to the CInema4D console window.

Jet Fluids 0.11 is now live. Did a bunch of stability fixes and also improved the workflow for using particles based simulations with the Volume Builder and Volume Mesher. You can find the change list over on the main site: https://www.plugins4d.com/jetfluids The sim time for this was 57 seconds on an Intel i7 10 core machine. I can't compare with X-Particles or Houdini since (1) I don't have them and have never done fluid sims in either of them. And (2) this is purely a CPU based simulation and does not use the GPU at all. But it will run anywhere. It even runs well on a 2013 Macbook 4 core machine. Watch the video below to see this scene being created and simulated.