kbar

All my plug-ins are now updated also. plugins4d.com

As far as I know the Scene Node system does actually interpret the node hierarchy and produce code that is then compiled to work directly on the architecture that you have on your machine. So it is actually a programming language. And eventually they will provide more higher level nodes to wrap around these lower level ones, which would then take it out of "tech preview" status and make it more artist friendly. I would like to see a scripting language implemented that lets me essentially write the node scene graph. One that also lets you debug the flow by stepping through it and inspecting values. I could then version control it in Github and have less worry about what line I accidentally removed from my pile of spaghetti that caused my capsule to break.

You can't multi-thread xpresso. That is the problem. That is why the new system is being created with multi-threaded at the heart of the architecture. The scene nodes will allow you to overcome the object count limitation that has plagued C4D for years. Allowing for hundreds of thousands, or millions, of objects to move around your scene. Scene nodes have a purpose and will be the future of a lot of new content in C4D. Essentially you can create capsules that are the equivalent, or surpass, the speed of C++ plugins. This is because the capsules code can run on the GPU taking advantage of all your system resources. Xpresso won't go away. But it is a very different system to the Scene Nodes. Scene nodes won't talk to Xpresso because then that would tie Scene Nodes to the Xpresso update system, essentially making it single threaded and reliant on all the other messaging going through C4D. However you could use Xpresso to control a Capsules parameters if you wanted. The same way you would control a Sphere for example. Since a Capsule can also create new geometry types (as an example), and expose parameters to C4D that Xpresso could control. Different things, different use cases.

They did recently hire Joe Alter.

Looks like something has broken. I see a similar report over on Cineversity. https://www.cineversity.com/forums/viewthread/5169/

Plugin is still available and still being updated for every new version of C4D. https://plugins4d.com/Product/aaOcean

Here is a tutorial showing how the radial smoke scene was created.

A GPU version was started but has been put on hold. I have my hands full with the current feature set. And I am now trying to focus on getting sample scenes for tutorial and marketing purposes to try to get the word out about it. As you can see from the GumRoad page there are only 140 customers right now. Maybe if there was 20,000 customers a GPU version could be funded.

Sure, will get the exact details either today or tomorrow. But these are super basic. Just a sphere with an emitter tag in a smoke solver with a radial field, outputting as external OpenVDB files and rendered in Redshift using the blackbody option in volume material. I intend on making a video showing all this when I have time.

Just added in support for subframe time stepping. Up until now it was fixed at 1. So just one simulation step between frames. But now you can set any number of Fixed subframes that you want, or you can choose an Adaptive mode which will adjust the number of subframes based on the maximum velocity of the fluid to ensure collision detection is accurate. However adaptive can lead to long simulation times without any indication of how long it might take.

Todays test was to try to recreate a FumeFX demo I saw a few years ago. The sphere has a cylinder shaped hole running through it, and in the middle is a sphere emitter that is emitting upwards. So the fire and smoke is then forced out the sides. I wanted to have a background shape in it, but I do not yet know the redshift render settings well enough to remove all the fireflies. And switching on the denoisers made it look pretty bad. This just has a very dim area light above the sphere. The fire in this render is a lot more intense because I have the blackbody emission set to a temperature of 6800 in the redshift volume material. All my other renders were set to 2500 so I could see the smoke more clearly. fume_26.mp4

Adding Fields support to the Smoke Solver. Here are a couple of renders. These are both using a radial field. smoke_sphere_vortex_render.mp4 smoke_sphere_vortex_2_render_i1.mp4

I purposely tried to keep the question as basic, and vague, as possible, to not exclude anyone from it. Do you use it? Do you double click that icon on your computer. Based on your experience here I would have said 100% that you use C4D. You write plugins. You are here on Core4D because of C4D. So if you didn't vote I count you as someone who never uses C4D at all and only comes to Core4D for other programs.

No, I feel like there is hardly anyone here that uses C4D anymore. As you said, it is just us core group that seem to be here now.

Only 53 people so far using C4D. Much lower than I thought it would be.

In the above I have set the temperature diffusion coefficient to 0.1 to let the temperature grid diffuse out from the emitter. The smoke is cached externally to OpenVDB files. Then I have used the density and temperature grids from the openvdb files in a Redshift volume shader, where the density grid is in the Scatter channel and the temperature grid is attached to the Emission channel.

Some smoke sims rendered using the new Redshift BlackBody options that came along with the S26.1 update. In all of the examples below, the simulations took only a few minutes. But the CPU renders took well over 2 hours on a 10core i7, while the GPU renders took about 30mins on a single 1080. Each of these is using the exact same setup, rendering 180 frames at 800x450. Cubic Advection (CPU renderer - 3 hours 32 mins render time) smoke_sphere.mp4 Linear Advection (CPU renderer - 2 hours 45 mins render time) smoke_sphere_render_linear.mp4 Emitting with an initial directional force (CPU renderer - 5 hours 54 mins render time) smoke_cube_cubic_render.mp4 Using a higher buoyancy density factor for the smoke to make it fall. (GPU renderer - 29mins) smoke_cube_cubic_heavy_render_2.mp4

At Greyscalegorilla we have a discord channel, it's free to join: Greyscalegorilla Discord - Greyscalegorilla And RocketLasso has a slack channel. Insydium / X-Particles, also has a discord. Even @Igorhas a discord: https://discord.gg/j6vfhYcN Probably loads of other discords and slacks out there. But for me personally I like forums because information can get lost on threads in discord and slack. Also forums get indexed by google. So you can search and find content. Meaning any long-form posts and information doesn't get lost. However that ability is now gone from Core4D because google won't be able to index any of these discussions. I prefer the community here as a place to hang out, and I also prefer the forum style interaction.

@IgorWhat was the reason again for making all posts hidden until you sign up? Was it too much traffic hitting the servers?

I have left the poll open for a month, so hopefully it will be visible to people when back from vacation. It does feel like there has been a drop off recently. The visibility of the forum being locked off to only those who have signed up will be a contributing factor. Since you can't even browse the forum now to see what it is about unless you sign up. So new users won't be here asking questions since they don't even know that this is a place where they can ask questions.

43 people so far. Are there really only 43 people each week that use C4D and visit this forum? Anyone else out there? 👀

Hey Dave, Yes I am the main/only developer for Jet Fluids. It is however based on the core algorithms developed by Doyub Kim (Fluid Engine Development). I really loved his book so integrated it one night for fun (about 4 years ago), and continue to improve it when I have time. Once I am happy with the integration then I will start adding more features to the actual fluid solvers themselves, but there is still lots of tweaks I can do to the current integration to make it easier to use for beginners. Right now I am just trying to show what is already there and possibly start writing a proper manual and create better tutorials. Not yet. But the smoke solver does produce a density and temperature in the resulting Open VDB, and these are cached internally already. However I haven't been able to use the temperature grid to get the look I was after. But perhaps with the new blackbody changes in Redshift this now may produce some better results. I will definitely take a look at trying it out soon with the updates in Redshift recently for the new blackbody changes. I did have a sub-step size parameter in the interface for a while, but I removed it because it wasn't really needed at the time due since I wanted to keep it simple. But I will look at putting it back in. Will definitely help with collision against polygonal meshes. Yes the grid solvers only affect the particles within the grid. But there is also an SPH and PCI SPH implementation which allows flowing out of the grid bounds. But I am not focusing on this solvers as much as the others right now. This video demonstrates PCI-SPH and unbounded simulation. Thanks. I am largely just doing this for myself since I personally don't want to pay for X-Particles, Realflow, TurbulenceXD, FumeFX, EmberGen etc... and because I have always been interested this area and want to see how it all works. And as a bonus I can provide an affordable solution to users who want to see what fluids is all about without breaking the bank.

You might want to look into the Sketchfab Configurator. I haven’t checked it out in a while, so it might be more user friendly now. https://labs.sketchfab.com/experiments/configurator-studio/ https://sketchfab.com/3d-configurators https://labs.sketchfab.com/experiments/configurator/

I have long planned on creating a tool that lets you author scenes in C4D and export out to the web. But I was unsure of the market. I was going to build it into my 4D Publish product. I may get back to it one day. But it is a niche in a niche market so sales would be low to zero.

LevelSet, FLIP and APIC are main ones. I rarely use any of the others myself. But I added support for them just to see how they behave. Here is a comparison of a dam break test for APIC, PIC and FLIP. The FLIP method actually has a slider to blend between pure FLIP and PIC. And here is the LevelSet dam break. And this one is PCI SPH. I didn't do one for just SPH since the implementation feels pretty unstable. LevelSet does not have particles and is purely grid based. But FLIP, PIC and APIC will generate particles that are moved through the grid. You would then mesh FLIP or APIC using either the JetFluids Mesher Object, or use the OpenVDB to mesh it. Smoke works exactly the same as any other solver. You add an emitter, then put a collider in the way and cache the simulation. Smoke however will create a volume and it is then up to you to decide how to render it based on whatever render engine you are using. Here is a simple scene (unfortunately I don't seem able to upload a c4d file or a zip of one to this forum).