Daniel Seebacher

Actually, looking now at the file, the compare node is probably indeed the better solution. Instead of enabling / disabling the emitter, have you tried using the birthrate (Editor) and birthrate (Render) instead? I get good results with those, and when I press play when the gun's recoil is set to 0%, no shot is fired from the emitter. The next question is if you want this to be a one-shot emission or a continuous emission. The above solution works for a continuous emission. If you want a one-shot emission only, we could try a solution that checks if the current birthrate of the emitter is set to 1 (which only happens when recoil is at 100%), and if this is true, set the birthrate back to 0. This solution would also need to check that the playhead is at least at frame 1, so that a shot can still be fired when the current time is frame 0. Note the file was saved with R23, so you might not want to overwrite your original project file. 472255043_DeathStarLaserCannon_v2_birthrate.c4d

Haven't had an opportunity to check the scene file yet, but instead of using a compare node, why don't you map the absolute position with a map node from [0;736.15] to [0;1]? You can discard intermediate values of the map node with a floor rounding of the mapping result.

Same for me. Something must have changed by accident.

Just scroll down and read the licenses paragraph. There used to be a comparison chart below which has now disappeared, because of the feature parity. So, there is no explicit comparison section anymore, because there's nothing left to compare anymore. It's now about the licensing only. I noted the site search and will see what I can do. It would need to be an incorporated site search, as I really dislike site searches that just redirect you to a Google search results page and make you leave the website in the mean time.

Dave, I have no idea how you found that page 😮it is from the old website and should have been taken offline years ago. It probably slipped through the cracks. But thanks to you, I was able to take it down now and redirect to the correct and most importantly CURRENT comparison page 😉 Thanks! I forwarded this to the sales team and they fixed the error in the store. Here are download links for the manuals. VUE manual PlantFactory manual PlantCatalog Exporter If you have any questions, feel free to ask 🙂 I recommend reading the blog posts for the new features. Even though you're mainly interested in VUE, PlantFactory is a massive release this time. Thank you for the nice words 🙂 I will forward them to the team and to Frederic, our vegetation modeler for PlantCatalog. By the way, PlantCatalog Exporter has also been updated with new features, so you should download the latest build and update. We'll send out a separate announcement about it to PC customers when the next plant batch is released (which will be soon). And cool animation and breakdown!

Yeah, I agree. I already created a ticket for the icons a while back. Admittedly, it's not a high priority ticket and it will stay like this for the 2023 release, because aside from fixing the bug, the code is frozen. But I'll pursue it for the next update. As for the rendering aspect, yes, you can get the entire scene out of VUE and then render it with any other application and engine of choice. You can either use the generic export from VUE standalone to FBX, Alembic or USD or you use the plugin. If you use the plugin, it will detect the render engine and automatically create materials for it. We currently support standard / physical, Arnold, V-Ray and Redshift materials in C4D. The Redshift conversion is currently the best one and we are working on bringing Arnold and V-Ray to the same level. Standard / Physical updates are not planned for now, because only very few people use it. Note that this applies to the current VUE version only. 2016 does not have this feature. In 2016, you can only use hybrid rendering, which means VUE objects will be rendered by the VUE render engine and C4D objects will be rendered by standard or physical. Rendering happens in one common pass, and shadows, GI and reflections / refractions will match between both scene parts. Here's a tutorial for Redshift conversion in 2021.2. A few things to watch out for: - VUE can handle more polygons and instances than C4D. For extremely large scale scenes, there is a limit what C4D can handle and if you are trying to convert billions and billions of polygons, C4D might crash at some point. - We are converting materials to Redshift materials and not to the new RS Standard Materials due to some remaining limitations. This will probably be updated in the near future. - Some things cannot be transferred during conversion, e.g. SSS settings. These need to be keyed into the materials by the user. - For some assets, you need to export them from VUE standalone and not convert them through the plugin, namely exporting the sky as HDRI and clouds as OpenVDB. We plan to centralize this in the plugin in the future, so that e.g. a RS Volume object with a RS Volume material is setup automatically during conversion, as well as a dome light with the exported HDRI. - Baking procedural materials takes time and they are of course limited by the baking resolution. If you plan to setup a scene and convert it to another render engine, we suggest you stick to bitmaps mostly. Also, we have a recording of a live presentation of the Spring GTC21 on our website. The last 15 minutes cover the various integration options you now have for VUE, so maybe you would like to take a look at it: https://info.e-onsoftware.com/learning-center/gtc21_creating_and_integrating_procedural_digital_nature You should be able to do this directly from PlantCatalog Exporter. The Clarisse export preset we suggest is based on USD, but if you select the preset and then switch it from "Clarisse" to "Custom", it unlocks the export settings and you can switch to Alembic from there and include the wind animation in the alembic file. Just keep in mind that alembic will carry over the polygon groups for the material assignment, but Alembic files do not include any materials and you will have to set them up and reassign them to the polygon groups yourself in Clarisse. Did you also try the PlantFactory plugin in C4D? 🙂

Oh, these look wonderful! I never played Magic the gathering, but I have a friend who does. I should take a closer look at his collection of playing cards. Thanks for the inspiration! Nice, thanks for sharing your delight 🙂 May I ask in which applications you use the exported trees? That's always interesting to know for us. You're welcome! Postponing a release is not funny, of course. I wish it wouldn't have been necessary. The deal will expire tomorrow and will not be extended. Even though I believe the sales team should be able to work out something on an individual basis for last-minute purchases 😉 The best price was during Black Friday, though (not surprisingly).

We had to delay the release until January, unfortunately 😞 we released a statement on Social Media about it. The release was scheduled for mid December, but we found a blocker bug at the very last minute which was not fixed completely before the holiday season. So, rather than rushing it out the door before the holidays and then hotfixing the bug weeks later, we rather wanted to delay and fix the problem properly. The release will be called 2023, btw. In hindsight, we should have called 2021.1 just 2021 and 2021.2 already 2022, because it was released at the end of 2021.

There still is perpetual 😉 the first time you let your maintenance expire, this is the perpetual build you will get to keep forever. But if you decide to go back to maintenance later, the perpetual build will not be upgradable anymore through maintenance. That's the difference.

@melisseta Not quite. Starting in January, every maintenance I would purchase would count as a new maintenance which would then run 12 months from my day of maintenance purchase. It won't be dated back to April 2022. If I purchase maintenance in January, it will run for a year. But again, it will count then as a subscription only and will not get me any new perpetual X-Particles build after the maintenance expires, because I was not under maintenance on January 1st. In order to stay in the perpetual cycle (if I was interested in this), I need to purchase maintenance BEFORE January 1st. If I do this, I am still under the old maintenance system where this will be dated back to my date of expiration in April, making the maintenance count as continuous, but which also means that this new maintenance I'd purchase would expire already in April. This would be the very last time that this would be possible. With the new system starting next year, there will be no option to purchase a maintenance extension months after your last maintenance expired which would be dated back to the expiration date. Instead, you will always have to extend your maintenance before it expires. Each maintenance you will purchase in the new system will extend your expiration date by 12 months.

@melisseta I can't answer the Cycles question on Reddit, but to stick to my license example: yes, indeed, if I decided to purchase maintenance before the end of this year, the maintenance starting date would be dated back to when my last maintenance expired in April. This means the maintenance I purchase now would expire in 5 months from now in April 2023 and with the new maintenance system starting in January, I would then need to get another maintenance before my next expiration date to stay continuously under maintenance and still receive new XP perpetual builds. Edit: Bezo is right. This is how it works. If you let your maintenance expire even only once, you would need to buy a completely new XP Fused license to get a new perpetual build of the current version. If you don't care about staying up to date on perpetuals, then you can of course let the maintenance lapse at any time and get back into the maintenance game at a higher price (250 pounds vs. 180 pounds) whenever you prefer. But then, it is really a pure subscription-only offering. You will be stuck forever at the former XP perpetual build.

X-Particles is perpetual. Everything else is subscription ( = maintenance). Included with a new license purchase are 90 days of free maintenance so that you can try out the other tools, including Nexus. If you like them, buy maintenance to subscribe to the features for one year. If you don't need them, no need to subscribe. Recently, Insydium changed the way maintenance works. Starting in January, Insydium will look at all existing licenses and check which ones are in maintenance and which ones are not. Licenses that are NOT in maintenance on January 1st are considered to NOT have been in maintenance CONTINUOUSLY. If you later in 2023 purchase maintenance, but you were not under maintenance on January 1st, once your maintenance lapses, the perpetual X-Particles build you will retain will be the build that you had once your last, previous, uninterrupted maintenance period ended. It will NOT be the X-Particles build you will have had once your "current" maintenance expires. Essentially, if you let maintenance lapse for some time and then get back into it, your perpetual X-Particles build will be frozen in time forever, based on when you let your maintenance lapse for the first time. Here's an example taken from my license: I have had an X-Particle license for a couple of years. My maintenance expired in April and I have not renewed since. The current perpetual X-Particles build I have is the one that was available in April 2022 on my expiration date. Now I have two choices: A) I decide to renew the maintenance until the end of the year (while the old maintenance system is still in place for the last few days) so that I have an active maintenance on January 1st. This will then count as having been under maintenance continuously. If I decide to let my maintenance then lapse next year, this will be the X-Particles perpetual build I will receive. B) I don't renew my maintenance until the end of the year. On January 1st, I will be considered to not have been under maintenance continously. If I purchase maintenance some time later next year and then let it expire, the X-Particles build I will then retain will STILL be the one from April of this year. I will not get to keep any new builds released in 2023 under my new maintenance period, because my maintenance was not continous. A bit confusing and it took me a while to understand it. Hope this makes sense to everyone.

I would like to take this opportunity and clarify some things about the integration workflow with C4D and the other host apps for which we offer the plugin. In my experience (and I was not with the company at that time, but still a customer), the xStream plugin in 2016 worked in fact quite well and way, way better than previous versions. The main issue is understanding how to use the plugin properly, because it is not as straightforward as other plugins. The workflow is described in the manual, but then, we are all guilty of not reading the manuals of the programs we use unless it's really necessary, aren't we? 😉 So, I know we need to educate our users better on understanding the possibilites and the limitations of the integrated workflow through proper tutorials. It's on my to-do-list for next year. In a nutshell: When you usually work with plugins, they are completely integrated into the host software, by which I mean that everything looks like native C4D editors and panels and that the objects created by a plugin can be rendered with any render engine, as long as you texture the object with a proper native material. The VUE plugin does not work like this. It runs as a sandboxed software-within-a-software where C4D acts as the "container" and VUE as an app is then launched within C4D with its own dialogues, UI and panels. I believe a good comparison could be Steam ( = C4D) which you have to launch first, and from there, you launch the game ( = VUE) which then runs "within" the Steam launcher. This means that the VUE objects listed in C4D's object manager are low-resolution, procedural proxy objects referencing the "fully" editable object from the VUE scene. You need to use VUE's native tools to edit all native VUE objects. After editing an object, the low-res proxy for the viewports is updated. For example, if you have a terrain object in the VUE scene, the terrain will be listed as a low-res polygon mesh in C4D's object browser. Of course, you could go ahead and start extruding faces and poly-modelling on this object with C4D modelling tools, but this will not be reflected in the VUE scene. And as soon as you open the procedural terrain in VUE's terrain editor, make changes and close the dialogue, the proxy object is refreshed / recomputed in the viewport and your manual polygon edits will be overridden. Look at the screenshot which shows the VUE objects in VUE's native object manager (the World Browser) and the proxy objects in the C4D viewports in the Object manager. Because of this workflow, you need to be aware what you can do and cannot do in the C4D scene with VUE objects. A big no-go is deleting the proxy object from the C4D object manager, to name just one example. If you delete the proxy object, VUE will try to recreate it as soon as you edit the "original" VUE object in VUE's editors, but if you try to launch a render while the proxy object is gone from the C4D object manager, you will encounter problems and instabilities, because the link between VUE and C4D for that object was broken and the VUE object just lost its counterpart in the C4D scene. So, adding and deleting VUE objects to the C4D scene MUST be done through the floating dialogues of the VUE plugin and through VUE's own object manager (the World Browser) which will then sync the changes accordingly to the C4D object manager and add / remove any proxy objects from there. There are more examples like this for which you need to look out, and if you break these rules, you are provoking a crash. This workflow is not obvious when working first with the plugins and we need to ensure that we educate and help our users more on these topics.

You're welcome! If you want to know anything, feel free to ask. 🙂 I just want to make clear that I won't be pushing any discussions or open any threads myself. While I do work for e-on, I am here in this forum as a private person who uses C4D both at work and privately. I am happy to answer any VUE and PlantFactory questions to the best of my knowledge when something pops up. I just don't want to give off the impression of advertising. I know the video you are talking about, and honestly, it's unsubstantial and just ranting for ranting's sake. If you look at that guy's channel, he has similar videos about many other programs. What he says about Terragen is not true. Which company would not like its customers to learn a software? This is nonsense. If you look at Planetside's forum, you will get lots of help from the community and employees alike. I don't want to take a stand and recommend VUE over Terragen or vice versa. Both programs have their strengths and weaknesses. Whether you need both or just one depends on what your focus is. For displaced terrain work, Terragen is the best solution thanks to its specialized micro-displacement algorithms and its reyes renderer. VUE on the other hand is the more complete package with more vegetation features and stronger integration. So it really depends. A quick word about tutorials: VUE and PlantFactory are bundled. When you get a license, you will receive both programs. Hence we need to ensure that there are learning resources available for both. The tutorials from the end of last year are still current, as the 2021.2 version was the last version released so far, with the new one for this year coming up in the next few weeks, as mentioned in this thread. Unfortunately, we are currently lacking a complete beginner course for VUE, but we're working on it and it will be released next year. At the moment, we are focusing our resources on releasing new PlantFactory tutorials. Thankfully, what Dave said about VUE's learning curve is mostly true. Many parts of the UI and the software are quite self-explanatory, even without tutorials. Of course, we still want to fill the Learning Center with VUE content. With PlantFactory, the learning curve is steeper, because it is a fully node-based program. And we all know that nodes require some time to be mastered and understood, whether it's geometry nodes in Blender, scene nodes in C4D or nodes in VUE/PlantFactory. Because there are not many PF tutorials out there and demand for them is growing steadily, tutorial production for VUE has currently taken a bit of a backseat in favor of PF courses. Thus, most of the learning materials we will release for the new version will be for PF, with more VUE content to come next year then. As for older tutorials such as AsileFX, they are still sufficient for learning the interface and the core functionality. Expect editors to look way different nowadays, though, and when it comes to nodes, a lot has changed and you will most likely not get the same results as in old versions, due to scale differences in scene units etc.; "Realism in VUE" from Dax is no longer really valid when it comes to specific lighting and rendering techniques mentioned in the book, as the lighting systems, atmospheres etc. have changed a lot internally. But it is still a good resource for general tips on how to build realistic environments, from lighting tips to sense of scale and more.

Dave, the comparison table on that page will disappear as soon as the new release ist out, because there will indeed be 100% feature parity between Creator and Pro / Enterprise 🙂 the only difference will be the license terms. For commercial work, you need Pro, for hobby work, Creator will be sufficient.

You can download the trial and test it. There has been a lot of code refactoring in the past years. Although I would suggest to wait a few more weeks until we ship the next update so that you can test the most recent versions.

Thanks, Jeff. I just saw your post in the Octane group which is where I also asked the original question 😄 I got several additional workaround suggestions in the group in addition to the ones from Matthew here and I will try them this weekend.

Hi Matthew, thank you for your reply. Just to be clear, I would indeed be looking for driving the other parameter with floats, not with textures or shaders. This seems to be possible in Blender then, judging from the screenshot. The Xpresso idea is very nice and I wouldn't have thought of it. I am looking for a solution though that would work across all apps that support Octane, so that it is a raw material-only solution without any app-specific workaround such as Xpresso. On Facebook, several people also suggested looking into OSL, so I might end up doing exactly this I think...

Hello everyone, I am currently trialling Octane for C4D. I have a mesh which has a vertex color set assigned where each channel holds a color correction value (Hue in Red, Lightness in Green and Saturation in Blue). The purpose of this information is to be plugged into a color correction node in the material graph of your render engine so that you can create "procedural" color variations within a material across the mesh. In any render engine, this is easy to do, but in Octane, I am struggling, because the Color Correction node allows only to control the brightness value with other nodes, but not any of the other properties such as hue, saturation, gamma etc.; there is no input circle on this node. I asked the same question in a Facebook group and somebody posted a screenshot from Octane for Blender where ALL the inputs were available. Unfortunately, I am not getting useful replies in the group, so I thought I'd ask here. Is there a setting I am missing somewhere for enabling the inputs for the other parameters? Is it a bug? Are Octane nodes in C4D just limited in general and this is by design so that only certain parameters of certain nodes can be driven with other nodes? For reference, this is how I would do it in Redshift and what I am trying to replicate in Octane. I read the vertex color attributes, "de-gamma" the color values because it's data, not color, then split it by channels, remap the ranges to the ranges the Redshift Color Correction node expects and finally feed it into the Color Correction node. Thanks for any help!

Happy it worked. It was a mere shot in the dark 🙂 Sometimes it's the little things that can be missed so easily...

In the above screenshot, the format dropdown is empty. Maybe that's why it's not working? Try filling out the dropdown and save again?

Realflow standalone does this too with Hybrido for large- scale fluids. You first simulate the fluid, then you can simulate additional (and much faster) separate passes such as foam or mist which reuse cached data from the main fluid sim. Then you usually mesh the core fluid and export foam or mist as particle point clouds. I've always wondered how you would render these particles then to look like foam or mist. Krakatoa can do this as a point cloud renderer, but I feel the plugin hasn't really seen many upgrades in recent years for any DCC. And the last supported C4D version of the Krakatoa plugin was R21. I don't know of any alternative for rendering convincing foam from particles though.

Davy Jones from PotC2? Absolutely amazing. If I recall correctly, every tentacle was rigged and animated individually. And yet, you could still see Bill Nighy's facial expressions.

I found the first Avatar barely watchable due to the awful script and the flat cliché characters. Disney did it better with Pocahontas. Have yet to watch the trailer for the second one. James Cameron has to try hard to convince me to give it a shot in theaters.

Does it work if you put the light into an instance object and then mirror the instance object?