Leaderboard

I'm not sure I understand the problem, but if it's to move the object manually (reflected in slider) and also move by slider, then a memory node set to 1F can detect value change ie is value != previous. slidervsvalues_0001.c4d

Thank you very much, it does work. I tryed two xpresso tags, but I didn't think of a switch. Python could be fine.

Not sure if posible directly in xpresso. Maybe creating two separate xpresso tags, one for driving rotation with slider and second one which drive sliders itself with standard rotation of object and adding some switch into the HUD for enable modes (xp1 On/xp2 Off and vice versa) something like in this short example (values are just 0-100 and 0-90 in degrees) just for imagine what I mean... (if sliders enabled ON, works sliders, if OFF, you could manipulate with object and sliders will be updated) slidervsvalues.zip ...maybe some short script in python could solve it...

I would not count out X-Particles just yet. When you compare TFD to XP in terms of rendering fire and smoke you have to ask what renderer is being used for XP. Is it Cycles, Redshift or Octane? What makes XP infinitely better than TFD (IMHO) is the ability create VDB files for rendering in 3rd party programs like Octane, Redshift, etc. You now have more power/control to render fire and smoke than using TFD's built in rendering solution. For example, the ability for me to control the amount of fire and smoke in a simulation is a lot easier to control in Redshift than in TFD....or even Cycles for that matter as I find that method a bit too complex. Now TFD does not create VDB files by default but its own BCF format and to get VDB output from TFD you need to run bcf2vdb from the COMMAND line prompt. Why so difficult? Why can't it just be an option within the program? Not sure. Another thing I love about XP is that it is a multi-physics simulation solution. Water can push cloth. Water can catch on fire. You have flow fields that can then impact volume breaking. You have grains that can be impacted by advection. Just a whole host of solutions. Now you do have multi-physics in Realflow, but Realflow is engineering grade - and really slow - and expensive. Every particle carries a ton of information and the file sizes are huge. It is GPU accelerated which helps, but all that aside, the maintenance/upgrade costs are still too high for me (close to 50% of the purchase price). Now, every fluid simulation solution out there is GPU accelerated except XP....so it stands to reason that XP needs to incorporate GPU acceleration to stay competitive. I have confidence that they will do it. Once they do, then (again in my humble opinion) they become the most versatile, powerful, easy to use solution out there that can produce amazing results when paired with a 3rd party rendering solution for the money. Dave

Well.....the next release is expected in the summer...according to their web-site. Now the summer technically extends until September 22....more than enough time for them to still be beta testing a GPU version. Now, GPU acceleration will be at the core of their code base and therefore all new features will be built off of that -- so if it is to be part of this release then it is probably already well down the beta test path. But don't expect to see it announced just yet. Insydium tends to orchestrate how they release their sneak peeks so that they build to create excitement. Each new peek tends to eclipsing the one before it in terms of "wow" impact. Pretty confident that this is both marketing and that the more complex (and thereby the more impressive new features) take more time to beta test to a point where they feel comfortable enough to announce it -- so their announcements naturally come at the end. Either way, GPU acceleration would be huge! An absolute game changer that would really get their competitors (like EmberGen) to stand up and take notice. As such, if it is to happen, don't expect to see it announced until right before it is released as it will be the climatic conclusion to their sneak peek release videos. Dave