Leaderboard
Popular Content
Showing content with the highest reputation on 04/28/2021 in all areas
-
Version 1.2
237 downloads
I have been using "Set Selection" on many occasions. Be it to create selection tags to apply different materials to an object. Or simply as kind of a clipboard to temporarily hold a set of selected polygons during modeling. However, in most cases I do not have enough with a single selection tag. It can happen that during a modeling session I need a few temporary selections, to be picked up later in the process when I need to work here and there on a model. As such, in the past I had a love-hate relationship with the "Set Selection" command. It was a very useful tool, except that it required me to always deselect the newly created selection tag before I could create another one. Reason for this is that if you perform a "Set Selection" with a selected tag, the newly selected items would be merged into the selected tag ... instead of being created in their own separate tag. I mostly use the Commander to quickly type "set se" and press enter. Or I would add the "Set Selection" icon into a modeling palette and dock it in the layout. Still, in order to be able to create multiple selection tags, I would need to execute the command, deselect the tag, and proceed with creating a new selection. NOT ANYMORE ... It finally annoyed me so much that I spend some time writing a script to provide the functionality to perform a "Set New Selection" ... NOT overwriting the current selection tag. This script will create a new selection tag of its own, use an appropriate unique name (just as the native "Set Selection"), store the selected items be it polygons, edges or points. I call it: Set New Selection. The good thing is, that you can execute this script from the Commander, or drag the icon into a palette and dock it into the layout. AND it can coexist next to the native "Set Selection". Which means you can still use the original behaviour if you want to overwrite a selection tag, or use the new one to create separate tags each time the script is executed. Isn't that neat? Yes, I thought so too! Does work with R16 - R23 (not tested with S22, S24) HOW TO install: - download the zip file - go to your Cinema4D preference folder (menu Edit > Preferences ... wait for it ... click button at bottom left "Open Preferences folder"). - navigate to library, then scripts - extract the content of the downloaded zip file here (or in a subfolder). - restart Cinema4D.Free1 point -
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.c4d1 point
-
Thank you very much, it does work. I tryed two xpresso tags, but I didn't think of a switch. Python could be fine.1 point
-
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...1 point
-
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. Dave1 point
-
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. Dave1 point
