3D-Pangel

A little confused by this whole topic and the request for real world examples....which is really a lot to ask. Nothing anyone "says" in this thread is going to be convincing enough as everyone is coming from a different place regarding thier "needs" when they make the decision to upgrade. You need to convince yourself and the only way to do that is to download a demo. As for examples of how some of these new tool's work, may I suggest the "What's new in RXX" series of YouTube video by Chris Schmidt at RocketLasso. Dave

You beat me to it. Also, please note that X-Particles is perpetual right now (everything else is subscription). Now that, like everything else in life, could change. With that said, the first demo shows 173,400 particles playing at 6.5 FPS on the GPU vs. 156,060 particles at 1.7 FPS on the CPU. So that is easily almost a 4 times improvement. Plus the hardware used is solidly in the mid-range. Not as high-end as I would have expected. So, IMHO, really amazing results when you look at the GPU and the speed of the CPU at 3.6GHz (which still has an impact as it drives the rate at which data is sent back and forth to the GPU). I mean both are good pieces of hardware. The RTX 2080Ti has 11Gb of memory and compute capability of 7.5 but there are faster and bigger GPU's out there. So, how does this compare to other GPU driven fluid simulation products out there? Better? Worse? Same? Dave

Very good analogy. Nurbs is a higher order (mathematical) approach and one level down from patch modeling. So I agree it is closer to "heaven" from a creation perspective (to keep that analogy going). Unfortunately, we live on Earth so it is a bit out of place for anything but 3D printing which is quite happy to live with triangles. I would hate to try and UV map textures to those converted models...or rig them. Nevertheless, a great tool for the concept designer looking to create 3D print models in the product development phase of a project. But with all that said, there was some very good UI design in that software such as mirroring which C4D could really benefit from. Dave

Think long term and with the resources of a monster technology company behind it. nVidia is a leader in AI and their GPU's are becoming the AI engine of choice. So don't be limited by what you see today. My post was based on what could happen in the not-so-distant future. Dave

When they start to create 3D scenes out of it (either real 3D or via projection mapping onto simple primitives), that is when a number of landscape DCC companies begin to get nervous. No DCC company can compete with the resources and technology of nVidia (they have a market cap of $662 Billion: 3 times the size of Adobe and 12 times the size of Autodesk) - especially as they are becoming a huge name in AI development. Fast forward 10 years, and you could see this technology being adapted to a number of other areas such as car design, character design, architecture, clothing and shoes, household products, and my dream application: space (planets, moons and nebulas) and science fiction. The only thing left in the DCC landscape would be animation --- but if nVidia goes this far, then imagine what they could do with AI for animation? Just type "make the monkey dance to I Gotta Feeling by Black Eyed Peas". Could it be that easy with AI in a decade's time? Never say never. Honestly, if you could just type a few words, sketch out something quickly and get a 3D model with full textures in seconds and then port that over to another AI application for animation and lighting, then type a few more words and make some doodles to a get a finished high-quality animation...would you still be using C4D? Be afraid DCC companies...be very afraid. For the graphic artists out there --- best start to focus on concept creation and concept design rather than execution as AI could be doing that job for you before you retire from your career. Dave

Thank you HappyPolygon! Ever since Cinefex went out of business last June, I have suffered a sense of loss. 172 issues and 40 years of commitment will do that to you. This definitely helps. Dave

You have keen eyes to catch that. When you consider that all those PC screen images are comped in as a post effect, then you have to wonder which company did that work and why they choose to use C4D to comp into those screens. I wonder if they used R25 instead then would you have noticed? And if you did, you would immediately go "Look that is C4D" or instead have thought "Huh! That is Blender on that monitor".

Honestly, I find the cost of these certificates a bit high given the financial benefits that they provide to the certificate holder. I base this opinion by comparing it to other certificate programs in a completely different field - namely getting a CCNA certificate (Cisco certified network associate). CCNA exams cost on average around $300 but the starting salaries of those with CCNA certificates are between $51,000 to $60,000. I am not sure what the starting salaries are for people with similar Maxon certificates, but even if you assume that they are in the same range, the return is better for a CCNA as the cost to get that certificate is 30% ($300 vs $1000) of a Maxon certificate. Plus, that $1000 only gets you a C4D Basic Comprehension Certificate. Is that enough to get a paying job or do you need to then shell out another $2000 to get the "Cinema 4D Trainer Certification". So that is a total of $3000. Now, getting a CCNA certificate is extremely hard as you need to know pretty much everything there is to know about each of the 7 layers in our telecommunication hierarchy --- and there are many communication standards for each layer. Absolute brute memorization that makes memorizing short-cut keys look like child's play. But that is not the point....the point is that the Maxon certificate programs seem a bit wildly over-priced as I am pretty sure that the salaries they command are not in the 6 figure range (to be on par with the ROI from a CCNA certificate). With that said, I will say that Noseman's training is worth every penny of a 6 figure salary and I sincerely hope he is that well compensated. Dave

Personally, all points being valid, I am just happy to see that slap-stick silly humor is still being made for kids. My fear is that, given the "enlightened" sensibilities of today's modern parent, there will come a time when all kids TV only contains a social message of some sort rather just trying to be funny and entertaining.

Wow. Learning soooo much. "SDS tension" captures the issue perfectly (I just called it bad topology) but you are right as that is exactly what is going on and once you think of the problem that way, then the fixes are really kind of obvious once they are pointed out to you (I only slapped my forehead twice reading Cerbera's solutions --- an improvement as before it would be 4 head slaps). This is a real master class. No software tool, remesher algorithm, plugin is ever going to replace what is in Cerbera's head. Dave

Honestly and with all due respect, are those facts? While it is a safe bet to offer the opinion that large scale simulations as seen in the movies of dam bursts or cities being flooded are the result of Houdini, I am not sure I could look at any of the small-scale simulations that you describe (beer, bottled water, etc) and determine what software was or was not used. A lot of what makes a shot look great is the artist behind it more than the tool that created it. I have seen both amazing Blender fluid simulations and crappy Houdini simulations. Also, overtime as more and more technical white papers get released, the technology does become homogenized across a number of DCC platforms. This homogenization of the technology takes the capability of the tool even more out of the equation and makes the talent of the artist the key differentiator. In short, the only fact I would hold onto in this debate is that it always comes down to the artist to make the difference between adequate, good and amazing fluid simulations regardless of the tool they are using. But, if "where" X-Particles is used carries more weight with your opinion of the tools capabilities than "how" it is used, then I respectfully submit the following link of X-Particle case studies: INSYDIUM LTD | Case Studies Please note that the first case study listed is for Rockfall Spiced Rum.....so I guess it is used for professional liquor simulations after all. Dave

Thank you for the encouragement and the comments. I will admit that the floor shine always bothered me a bit as well but if you look at Return of the Jedi (which this bay is mostly based on), those floors are pretty shiny: But, as I said, they bothered me as well so I completely redid them: Now I need to add little touches of equipment on the floor to break up the image a bit because right now it just a big sea of black. Dave

Now that playoffs have NFL have concluded and this weekend is only the Pro Bowl (which no one really watches anyway) and there were no ice storms or blizzards to contend with, I got back into this WIP. The cargo pit in the floor has been added: The detail on the walls of the cargo pit was modeled....probably could have gotten away with a texture now that I look at it. Dave

That is just too cool for words

I did not mean to be off-putting to you or anyone else. If that is how I came across, then my sincere apologies as I do respect your opinions and experience. So, with that said, let's go grab a glass a Don Julio #70 together ---- for scientific purposes only. To study the ice and the fluid interactions....yeah.....for that only!!!😀 Dave P.S. In case anyone is wondering, while an extremely infrequent drinker, I really do enjoy a glass of good tequila.

If I may recalibrate the discussion a bit. The issue is NOT that there are commercial projects out there that will require a dancing monkey to wave a burning flag on the beach while getting hit with an ocean wave (cloth, grains, fire, water and character animation). The issue is NOT that Houdini is the ONLY program in all of existence and for time immortal that could ever attempt such a task. The point is NOT how inadequate C4D and/or XP is at anything slightly more complex that FUI effects for the Marvel movies. The point is that the workflow to create such a project outside of the host DCC app will be FAR more difficult than using a plugin that exists within the DCC app or having those capabilities built into the DCC program itself (like Houdini or Maya). This point was made based on JangaFX's products being standalone programs. So, in keeping with the point of this thread, this is a workflow discussion around JangaFX's approach to fluid simulations. Properly implemented fluid simulations are recursive calculations when they involve solid objects: the fluid moves the object and that moving object then affects the fluid simulation. Therefore, for all this to happen outside the host application usually entails that your animations need to be cached up to the point of export to JangaFX and then what you get back is a cached file of the simulation and the animation which can then NOT be changed without repeating the whole caching and export/import process all over again. Not an impossible hurdle to overcome but just a bit more cumbersome from a workflow perspective than what you would have with fire/smoke as the fire/smoke simulation does not affect the motion of the animated objects in the host DCC application. Again...just a bit more cumbersome...but probably enough to be annoying and therefore in need of a solution. This annoyance grows if LiquGen and Embergen remain two separate applications and you need to jump from one to the other if you want fire and liquids to coexist together. So, where I was hoping this conversation would go is that with the introduction of fluids simulation, JangaFX realizes two things: Fluid and fire simulations need to be able to work together Tighter Integration with host DCC applications (and not just 3rd party rendering applications) needs to be part of their development timeline when they introduce LiguiGen. Therefore, over time and in response to these issues, will the introduction of liquid simulations to JangaFX's toolset drive a rethink on their approach to being platform agnostic? JangaFX makes great products, and I am sure they will continue to grow in adoption over time. Therefore, with that growth will they feel the need to offer plugins for their stand-alone applications as well? That is where my mind was going when I brought up the issue on LiquiGen workflow. But if we want to keep praising Houdini, bashing XP, and/or bashing C4D then can we at least do that in a separate thread? Dave

So essentially, you are advocating that any fluid simulation system outside of Houdini should only be used for single system physical simulations like filling a glass with water? So simple non-VFX big budget scenes like ice cubes floating and moving around naturally in that glass during a product shot of Don Julio #70 Tequila being poured over ice should immediately cause the artist to bail on C4D and start learning Houdini? Not sure how you could do a natural interaction of ice and fluids realistically in a product shot where the fluid simulation pushes and moves the ice around while the moving ice also affects the motion of the fluids. That is a multi-physics simulation at its most basic. I don't know, but simple product shots like that are keeping it real and are the bread-and-butter shots for the independent artist. While I have not surveyed the entire industry, I think it is safe to assume that the first "go-to" tool for artists working in the product advertising field is NOT Houdini. Also, what is the point of GPU enabled fluid simulations if they are ONLY going to be used for simple scenes? Sorry, but my original point stands. If you want to do more than filling a static non-moving glass with water and get into multi-physic simulations, then the workflow using a JangaFX's stand-alone apps becomes a problem. And if all you are going to do is fill a static glass with water, then that is something XP can handle today very easily and completely within C4D. Dave

Apologies if this post is a repeat but I think it got wiped out when Core4D had its crash this weekend. I do agree that being able to download the Maxon asset library one asset at a time (as opposed to the entire 6 Gb file) has its advantages, but does it also mean that access to that asset library is just one more perk ONLY available to subscription licenses holders? Dave

You make a very compelling argument for creating smoke and fire. But I fear that workflow will be tested for LiquiGen as fluids not only get impacted by an object's animation, but they can also impact the motion of the object itself. For example, imagine a burning flag being hit with water. Here you have cloth, liquid and fire simulations all working together: liquid can push cloth, cloth can push back on liquid and the moving cloth can then drive a fire simulation. To manage each one those simulations discretely would be a series of best guesses to get right and therefore very difficult. This is where XP has an advantage as the underlying architecture for each simulation is particles. Cloth simulation set's each vertex of the cloth as a particle. Those particles can then be acted on by the particles in the fluid simulation and in turn the cloth particles can affect the motion of the fluid particles. I think this used to be called "n-systems" level of simulations where multiple physical simulations can work together. Now, pretty sure JangaFX will get there but it will be dependent on caching those animations during export - which locks you in. For example, say you want a tidal wave to overtake a moving car and then push it down the road. The car will be key framed prior to export but will then its entire animation will then be cached and locked in after you import it from JangaFX. I hope (and this is the big dream) is that fluid simulations do take a huge amount of time to get right and by the time JangaFX reaches the same level of interaction that you can get with XP today, XP has been ported to run on the GPU.

A nice greyish blue actually. I kind of like it. But with today's digital compositing tools, is color inversion still part of the process as I thought it would all be based on difference matting/color keying. Dave

Not sure if anyone picked up on this, but notice what they used for background compositing: Had they used blue or green screen, then the reflected blue or green created by those screens would have thrown off the overall color tone/saturation on the actors/props. No matter how well they were matted into the background, the lighting on them would have been slightly off from what it would have been if they had actually existed in that environment. This is the level of attention the VFX artists/supervisors pushed for with Dune and why that movie just looks so much more real than what you would find in a Marvel movie or any other big budget VFX movie. You can see that philosophy talked about in how they even shot the Ornithopter's using t wo helicopters to get real life camera distances, angles and dust effects. Other things to note when watching Dune: The star's faces are not always perfectly lit during a VFX sequence. They go into complete darkness when a VFX explosion goes off in the background because that is what would happen should an actual explosion been filmed. The camera would have dropped a few F-stops to get the exposure on the explosion correct while throwing the foreground actor into complete darkness. Normally, the mentality is "keep the big budget star visible at all times as that is what the audience is paying to see!!!" Err...not really. Dave

Progress on this WIP continues. The ceiling rails and mechanicals are taking shape and were patterned after the ceilings in the docking bays designed by Ansel Hsiao. Ansel's reference photo: My take on that design: And how it appears in the full model: I could probably add a few pipes up there, just to create a bit more visual "noise" to break up the pattern. Next up.....finish the back wall (including working blast doors rigged with Expresso) and adding the cargo pit in the middle of the floor. Dave

Glad to know that Igor is doing well and quickly becoming a name in the Houdini world! This really is great news. Dave

I would imagine that if you don't have Octane, the only value of fine tuning the look of the simulation in Embergen is to validate that your channel settings for heat, temperature, density, etc are correct because the only thing you will be exporting are those channels in the VDB file. You would then need to fine tune everything again for Redshift. I know Embergen's real-time feedback and GPU acceleration make it very attractive over X-Partlcles, but to me the workflow of using Embergen has a few more steps - especially if you want a 3D element to interact with the simulation. Am I understanding the workflow differences correctly? If so, I wonder if the workflow advantages of real-time fluid simulation feedback in Embergen offer that much of an advantage to a non-Octane user --- particularly if in Step 3 you realize that you want to change how the animated object is interacting with the fluid simulation. Now, if Embergen worked with Redshift and/or made plugins for DCC apps like C4D, Maya, Houdini, then I would definitely be jumping aboard the JangaFX bandwagon. But right now, I just don't see it. If there is something I am missing, please let me know. Dave

Wow...that is really ingenious how you did it. Sometimes, creating a low tech look can only be accomplished with a high tech approach. So you want just the shadows to be heavily pixelated? The first thing that came to mind was to use shadow maps with an extremely low resolution but the lowest custom setting in C4D was 40 x 40. That created this result (settings to the side) So while the pixelation is there, it is not as pronounced as you desire. Another approach would be if you had Redshift and set the initial ray cast levels extremely low as well but that could have other unintended consequences. Interesting challenge to make something look 8 bit with 64 bit tools. Dave