3D-Pangel

No. You are just selecting how you want the simulation to be calculated...similar to how TFD works as you can select CPU or which GPU you want to use. Now what the video did not show was the ability to switch between CPU and GPU in mid playback (uncheck GPU and it goes back to using the CPU). That may or may not be possible. Honestly, I think it is pretty silly to have an xpFluidGPU node that you not only have to add to the scene but then select as on. Ideally, once you add it to the scene, the default should be on and it is no longer using the CPU. Maybe that will happen in a future release once GPU enablement is ported to all areas of XP. Dave

I would agree. I know that there are tools out there that have complex algorithms for tropism and branching (L-systems), etc. But for my uses, foliage is mostly background filler and not the main centerpiece. Now, I have nothing but admiration for those artists who create some amazingly intricate details in a tree that are just gorgeous to look at. They can be an art form all unto themselves and I appreciate both their complexity and the talent required to create them. But for me, Taiao may be in the sweet spot. The interface seems straight forward and easier to navigate than Forester (IMHO). Again, as my need is for background filler, my wish is that the animation capability for anything other than grass exists. My really big wish is for dynamically driven tree's that interact with other dynamic systems via spline dynamics and particle interactions (fluids hit trees and the tree sways and falls over). If Insydium sticks to their schedule of a new "sneak peek" every 7 to 10 days, we may see something tomorrow. Dave

First off -- whatever comments I make, please understand that I thought this animation was outstanding. And not just the animation, but the music, editing and sound design. Really exceptional. What fooled me the most were the people. I thought you cut away to live action, but it wasn't until the last shot of the film that the old lady looked animated. The nighttime lighting was just superb. One technical thing you missed were the spark emitters to burn off any waste gases near the engines prior to ignition. Relative to the fluid simulations.....they were, for the most part, very good. There were only two shots that needed improvement: the water jets to cool the pad and the final shot of the rocket ascending into the sky. The water jet was good but could be better but I think you are being limited by the XP more so than your talent with it. That water needed to be pushed out with the impact of a large scale water sim and XP just can't do it. That would be a job for Houdini only. The final shot of the rocket ascending into the sky was just not good. There was simply no thrust and no smoke plume. You could still see the stars below the rocket when they should have been completely blacked out by the smoke. You really don't need to see the smoke because it is night...only what the exhaust illuminates. The fire you do see is too long, too wide, and too much turbulence so it is going all over the place like a candle in a breeze. All this makes the rocket look small. It should be a defined short blast disappearing quickly into a lighted plume of heavy smoke. In fact, as it is at night, remember the camera exposure will be set for you to see the rocket and not the exhaust. So you could cover most of that exhaust it with one big blinding flare: But that is it. Just the last shot needs to be better in what is still and outstanding display of way more talent than I will ever have. Great stuff indeed. Dave

Whenever I talk to Daniel about Vue, I don't feel multicultural. I feel completely stupid. And not just about my preconceived notions concerning Vue from 6 years ago but also the entire landscape generation 3D industry as a whole! His ability to explain Vue, e-on, and the industry in the clearest most concise manner possible just blows my hair back. His explanation as to why xStream may have crashed C4D was news to me....and it makes complete sense. I wish I had known that before. But, as I said in a previous post, the whole move to increase export capability and the deep integration with Redshift is leaving me with only one concern about getting back into Vue again: their subscription program. Unfortunately, there is not much Daniel can do about that. Be sure to catch his training videos found here (a growing collection with the newer ones, particularly those discussing Redshift, belonging to him). Dave

Two a certain extent, I agree with you. Insydium is at least holding on to perpetual licensing for their primary app, XP. But, like Maxon, they are putting aside growing XP's capabilities in favor of developing new apps to fill out their Fused portfolio. Both companies are pushing for growing their subscription base and are chasing after re-occurring revenue. Maxon is doing that through acquisition simply because they have the cash to do so whereas Insydium is doing it organically from within. But both companies are moving in that same direction. Now, to be fair, the lack of new XP features over the last two releases is because most of the effort on XP is GPU enablement (which is huge). This is, in effect, the birth of a new core for XP which is always tricky. Also, Maxon is constantly changing C4D with each new release as well....and they are doing it two times a year (though I would imagine R25 gave Insydium a bit of breathing room). Plus, C4D is inherently a CPU centric DCC app so no assist there from Maxon's SDK (to the best of my knowledge -- feel free to correct me if I am wrong). So, keeping up with all those releases and working in GPU enablement into a plugin for an inherently CPU centric DCC app is quite the non-trivial undertaking. So I certainly understand the lack of XP new features during this period....but still, resources are expended on growing Fused during this resource intensive activity, so my original point holds. What has me puzzled is that Insydium has only 1 software engineer with the title of "GPU architect". He is a "Senior" GPU architect, which would imply that there are other GPU software engineers on the team, but that is not reflected in their titles. So is this a 1 person effort for all of XP? Or is he directing the other 5 software engineers? Plus, when you consider Terraform and now Taiao development, that has to be consuming all of Frank Willeke's time, then that leaves 4 other software engineers (maybe 3 as I have no idea how much effort is being expended on Meshtools or Cycles on-going maintenance - if any). So, does Insydium have enough resources to work on a completely new core for all of XP to get it released in a year? In two years? I hope so. Dave ADDENDUM: It just occurred to me that should XP's new GPU core get bogged down in development hell, and Jawset and/or Embergen comes roaring to the forefront with their fluid applications in the meantime, then Insydium may actually want to be acquired by Maxon so that they can tap into the GPU experts behind Redshift. Just a thought.

Unfortunately, you are right. Should Maxon ever feel the need to add landscape generation to their Maxon One bag, I suggested in another post that Vue could be a pretty cheap acquisition from Bentley. But picking up all of Insydium would probably be the smarter move. Dave

As a VFX enthusiast for over 40 years, Cinefex was my go-to source for exceptional behind-the-scenes journalism. Their demise last June after 40 years was a big loss. There have been some sites out there that have tried to fill that void, but not at the same level that Cinefex did. Their writing and photo documentation was just exceptional. Well...I think I found an on-line source that looks to be a worthy successor: The Art of VFX They actually have been around since 2018. It was actually a bunch of Twitter feeds that brought them to my attention. Dave

Wow...what a downer. You just killed my joy! 😀 Remember that as long as Insydium is making big money on their own, then they are not motivated to sell. So let's hope that their success keeps them independent. Also, Dave O'Reilly (Insydium Founder) left Maxon for a reason. So if Maxon did come calling, I would imagine it would take a pretty sweet offer for him to be folded back under Maxon again. Not saying that won't happen but I don't think it would an easy negotiation. Mr. O'Reilly's accomplishments (and the justified pride that goes with it) will not come cheap. Dave

I would agree. And this will give Forester a run for its money as well. In fact, Insydium in one short year has already replicated everything in Forester but also the long awaited, but never released, RockGen plugin as well. 3D Quakers must be a bit despondent right now. Now, TAIAO has wind force modifiers. But they were only shown acting on single spline systems like grass. What I would want to see is there action on multi-spline systems like trees where there is more dynamic motion on the leaves then the branches but both the branches and leaves are impacted by the wind. To just see the leaves move but not the branches would be a bit of a disappointment. They kind of glossed over this at the end of the video very quickly. The population tools look very good but more needs to be said here as well. For example, can the population be controlled by the view angle of the camera. Tree instances will be created based on what the camera can see only. Better yet, tree instances will be created based on what trees and their shadows can be seen by the camera. Also, as the trees are procedurally generated, is there any LOD functions as well. Finally, relative to tree dynamics, will the main points in the tree splines get converted to particles and therefore be impacted by XP forces? The backbone of all XP n-systems dynamic simulations is that everything is defined as particles. The particles in a cloth grid are part of the same dynamic system as the particles in a fluid simulation. That is how a fluid simulation can impact a cloth simulation. So can this n-system methodology be extended to a dynamic tree simulation. Imagine an XP explosion causing the trees to rock back and forth. Or the trees get knocked down in a flood. Or you populate a landscape with trees but then use Voronoi fracturing to break that landscape up and collapse and the trees sway and fall in that landslide. Now that would be cool. So this is pretty exciting not only from a landscape generation perspective but also from a deeper integration with XP for future VFX possibilities! Great start! Looking forward to it. Dave

I also had a bad experience with Vue xStream. Extremely slow and constantly locked up. But if you had xStream then you could also run it in stand alone mode and there I had no issues. Unfortunately, you did pay a premium for xStream and to have it be so frustratingly slow and unstable was horrible. There was a plugin in C4D that used 6 orthogonal cameras which were perfectly aligned to generate a sky box so I was using that plugin and xStream to create sky boxes (another software program converted those 6 square renders into a spherical sky map). That was about all I was using xStream for because the spectral atmospheres was pretty cool and far more realistic than that sky shader C4D had. This was back in 2015 prior to the Bentley acquisition, the e-on site hack, and essentially no upgrades for 2 years. So it was pretty easy to walk away from. But I have kept my eye on it as working with Vue stand alone was a nice experience. Still no love for subscriptions though. Now take a look at the Bentley web-site. They do not even list Vue as one of their products. They only list LumenRT which was once part of e-on. Bentley is all about construction and industrial design and project management software. Vue is the red-headed step child you don't talk about in that family. Is there a commitment there to Vue? Not really sure. That is troubling. Honestly, if Maxon wants to grow Maxon One just a little bit more with another acquisition, I bet Bentley would sell Vue to them for a song. Vue is coming on nicely with Redshift so who knows. Dave

Well...don't we all?

I think Vue has that capability and is one of the options in terrain generation. Here is some detail from their web-site: Now, I have to say that Vue is beginning to become attractive again from a feature perspective. There is also a big push on Redshift integration, import/export of all elements (including clouds), render optimization and I have always loved their lighting models. The big downside is their subscription model which ONLY comes with the bundling of Vue and Plant Factory. And personally, I am not too thrilled with Plant Factory. Honestly, it just seems like too much effort to master to only make a tree. I would rather just pay less to get Vue and import trees from Forester. Dave

Terraform was a one-person operation --- that person being Franke Willeke who now works for Insydium

Agree. My second wish would be tree instancing and population capability. Given that Terraform is being developed by Frank Willeke the developer of SurfaceSpread (now owned by Laubwerk), I would hope that capability is forthcoming --- unless Frank is under some non-compete clause from Laubwerk which prevents him from re-developing that code. Changing subjects, when you look at the Insydium team, I noticed that there were NOT as many software engineers as I would have expected and only 1 engineer dedicated to GPU Architecture. Here is the breakdown: So for 27 employees and 3 main applications (4 if you count Cycles --- but it appears that is being dropped) you only have 6 software engineers, 5 designers and 2 quality engineers. Is that properly sized? Honestly, it feels a little lean to me but then again software development is something I know little about. Also, one of those software "engineers" looks to be Dave O'Reilly's son and while I take nothing away from the contributions of his very talented and intelligent son, he does look a little too young to have a software engineering degree. But, with that said, I would not be surprised if his son was a genius and graduated college at a very young age. Now, conversely, they have 8 people devoted to web development, marketing, customer support and IT. So a big focus on license server management and marketing. Is that also properly sized? Again, I have no idea...... ....but.... Does this show a strategy where more resources are being devoted to growing and marketing a suite of products under a subscription licensing model rather than expanding the features of those same products? Now I am NOT saying that Insydium is no longer concerned with feature development. What I am saying is that, from a revenue perspective, attractive subscription programs yield a higher return so that is where the resources are going. Therefore, is it fair to say that just as Maxon is more concerned with Maxon One than they are with Cinema 4D, so is Insydium more concerned with Fused than they are with XP? Dave

Well...Insydium releases these videos one at a time rather than all at once (maybe this improves their hit count on YouTube or they release them as the features become available). So I would not judge them yet as I would expect (or hope) there are more to come. But I do agree with you regarding redundancy to C4D native tools. My hope though again (I guess I have a lot of hope for Insydium) is that their versions can do more than their C4D counterparts....if only because their tighter integration with XP. Dave

Just noticed that Insydium posted a new sneak peek video 4 days ago on Terraform and before that was a Mesh tools update (see them both here). Not that interested in Mesh tools but Terraform has made some pretty good enhancements to landscape creation and closing some workflow issues with landscape editing. The road system is also pretty interesting. The cover image is a bit deceptive though as it shows a lush forest giving the impression that Terraform also has made improvements to its ability for distributing trees across a terrain - but that is not discussed. Maybe it will be discussed in a future sneak peek video. We can only hope. Dave

So is it safe to say that with 3 PC's priced between $3K to $5.2K built since 2015 that your total costs were (at a minimum) $3K + $3K + $5.2K = $11.2K Now was the dedicated VR room for you or someone else (eg. not your cost)? Even if that was the $5.2K machine, then (again at a minimum) you spent $6K. That number makes more sense to me as it about matches what I spent in 2015 for the machine I still have today. It still works well which is what keeps me from replacing it. I hate to just stop using something that still runs and only holds me back a little bit and with an 8Gb K5200 is a little undersized for Redshift. Now, I did speak of discounts I get from my employer program and some of those are very attractive. But still it comes down to what I can afford vs. what I want. Still though, there are just some deals that are too good to pass up and this was almost one of them: Now, this deal landed in my lap at the worst possible time during a Black Friday sale in December, 2021. There were the usual Christmas bills, my daughter was starting her master's degree program in data science in January, and the house needed some work also planned for January. So I passed and I am still crying about it because I will never ever see these prices again. As a side note: the cash back program my company offers can be used for future purchases only. Now, as I need a new cell phone (I still have an iPhone 6), that $1,305 cash back money would have gone to an iPhone 13 --- so for me it is still money saved. So my question to you as someone who very frugally and wisely builds pretty powerful machines for the least cost, would you jump at this deal? Dave

May I ask what your annual budget is for PC hardware? On average? Best guestimates work too. I get the sense that you are constantly upgrading components whereas I do it in 5 or more year intervals with an entirely new machine. Knowing if the two costs are equivalent (when averaged yearly) would be interesting. Dave

Please tell me that this is parody. Honestly, I can't tell anymore....which is a rather sad statement on the world where everything and anything can become a cause.

Interesting insights and much appreciated especially as you mentioned TFD. Here is why: I keep my workstations an extremely long time (it takes that long to save up for their replacements). My current workstation was built in 2015 and has the Quadro K5200. So, it is getting close to 7 years old, but it still runs well (disclosure: it did have some warranty work done which attributed to its endurance but that is another discussion). But what makes it relevant is that I actually contacted TFD's developer at the time concerning NVidia's compute capability index and VRAM. Essentially asking the same questions I am asking now and asking his opinion on the K5200 with 8Gb of VRAM. His response was along the lines of "Wow. I have never run TFD on a card with that much VRAM. I am really excited to hear how it performs on the K5200". Back in 2015, 8Gb was considered the "more than enough" limit to fuel your creativity. Today it is entry level. So, what is moving the needle on VRAM requirements? Has our appetite for more complex scenes with higher fidelity increased as the software/hardware improves? Does the availability of more powerful hardware at cheaper prices taken the edge off of writing more memory efficient code to stay competitive? Or is it a combination of the two or something completely different altogether. Which direction is this going and what is the key driver going forward? It feels like 24Gb is the "more than enough" limit for today just like 8Gb was the limit in the far past. But for those amateurs who like to wring out every last dime from their hardware investment, is that a correct assumption? Dave

How does Octane handle two GPU's? I would imagine you would need NVLink to get their memory combined. I looked at two A5000's with NVLink compared to one A6000 --- both options came to 48Gb and there was very little in price difference between both solutions. So if I wanted 48Gb it would be A6000, but that is a huge price increase over the A5000 and it is only marginally faster than the A5000. Thus the thread's focus on VRAM as the issue is what would I NOT be able to do with 24Gb of VRAM that would make the A6000 attractive to me (and given the price difference it would have to be significant) As my interest has always been environment creation and VFX (in particular fluid simulations), has anyone every run into a limit and if so, what was your GPU and what were you trying to create?

Don't burst my perception Cerbera. You created that using nothing but quads and two scene nodes!!! 😃 Still though, someone had to come up with the procedural algorithm and that is where the genius lies. And for those who love the inner mysteries of math....try this one out. 1) Pick any whole number from 1 to infinity. 2) If it is even, divide by 2. 3) if it is odd, multiply it by 3 and add 1 (3n+1) 4) Go back to step 2 and repeat with this new number. No matter where you started, the sequence will end with 4, 2 and 1. Have fun. Dave

Wow...and that diatribe was the edited version! Really, it is okay to be unhappy with C4D and that is one of the nice things about this forum and its moderators but to bring up some social media hot buttons and then say it is not a political post? Honestly, this is not the place for it. Dave

I guess the type of feedback I am looking for is probably exactly like the type you provided: "I have XGb of VRAM and have done A, B and C without any problems" or better yet "I had XGb of VRAM and could never even attempt to do A, B, or C until I upgraded to YGb of VRAM." Dave BTW: That is an amazing render. It takes a very special mind to figure out how to create something like that.

While thoroughly enjoying a similar thread started by Iceman called "3D Choices for 2022", I thought I would start a more focused discussion to address a burning question I have had for quite some time: Just how much VRAM do you really need in your nVidia GPU if you want to get the most out of your GPU rendering application? For example: Redshift's memory management is really good and can handle 300 million triangles with 8 to 10Gb of VRAM due to its out of core architecture, but that may not work with VDB files (out of core architecture cannot handle volume grids). So how much do you need to add if you are working with VDB animation files (clocking in between 20Mb to 200Mb or more per frame). Also, what impact do texture sizes have? Assume I am using 8K textures across the board! Does that eat up more VRAM than geometry? Do large particle simulations consume huge amounts of VRAM? The over-arching guidance you get is "the more VRAM the better" but you really do pay a huge price premium for anything over 16Gb. So, what is everyone's experience? Where did you hit the wall and why? Were you doing fluids? Large particle simulations? Wrestling with 16K textures? All three? Or you have yet to hit that wall with an 8 Gb card and see no need for going bigger. But if you have upgraded or you want to upgrade, then what is overkill regarding VRAM? 12Gb? 16Gb? 24Gb? 48Gb? There is no such thing as VRAM overkill with GPU rendering. Break the budget, mortgage the house, sell a kidney! Do whatever it takes to get as much VRAM as you can because you will never regret it. Save your money. It's not the amount of memory but rather the number of CUDA cores where you get the best return on your dollar regarding render speeds. Again, the focus is on rendering and not viewport performance where the host application can get in the way. Thanks, Dave