OTOY Forums

Hi does octane work with new Phoenix fd version 2.25 [available on chaos forum as nightly build] It is the newest version where 2.20 is old official version that is not really used anymore like 2 years ago.
Version 2.25 is very very different. (Liquid sim grid and fumes and smoke are separate sims, wetmap is not mesh anymore but particles that vray material uses to blend two materials to create wet effect) Will all this work with octane 3 4.1?

3ds max 3.0 4.1 supports PhoenixFD what about splashes and bubbles. Will octane support it?

coilbook wrote:what about splashes and bubbles. Will octane support it?

There is no access to this PhoenixFD geometry data in its SDK.
But I'll investigate later if it is possible using some non standard tricks...

Thank you
We will go to chaos forum and see if chaos can help too

Here is their reply in this link http://forums.chaosgroup.com/showthread ... post699066
I just hope one day octane can render bubbles, splashes, etc

{"Octane is a GPU engine; it can't possibly use the 3ds Max API for rendering. " I guess this is one of the biggest drawbacks of GPU rendering. Nothing is supported}


or our conversation bellow

For the moment we are focused on our next version of Phoenix FD and our priority for that is seamless rendering with V-Ray. With that said, it should be possible to extract information about the foam/splashes particles in recent builds - I know we had to do it in order to get the exocortex crate and 3ds Max's native Alembic exporters to work. However it is the render engine's responsibility to do something meaningful with that data, i.e. apply proper foam/splashes shader to it.

Best regards,
Vlado


Actually Phoenix FD is quite friendly to other render engines, all the phoenix objects are obeying the 3ds max specifications and are accessible via 3ds max SDK, that's why we provide no SDK. Really, some features of Phoenix are working only with vray, but you will be surprised how low in count they are. You can achieve perfect ocean scene without VRAy, only using the standard 3ds max features.
The problem with Octane renderer is that it is not actually a fully integrated 3ds max rendenrer and does not support some very important 3ds max specifications.
1. Atmosphere support. If this feature is not supported, the renderer will be not able to render fire, smoke, splash,mist and foam.
2. Event notification (pre render, post render, etc). If this feature is not supported the renderer will be not able to render ocean, because the mesh LOD is different in preview and render mode.
3. 3ds max maps support. If this feature is not supported, the renderer will be not able to use the particle texture and the phoenix texture, making any advanced material setup impossible (for example wetting)

The features requiring VRay are:
1. Heathaze fire rendering
2. Reflections/refractions of closeup splash and foam
3. The foam water tint. About this feature we have provided work around, you can specify color tint in the foam shader, so we can consider it compatible with other render engines.
So, the only really important feature requiring VRay is the closeup foam reflections and refractions, i think 99% of the cases are not requiring this.

edit: i have no registration, but you can provide this info to the Octane team in the forum, at least the foam can be integrated in the same way they used for the smoke


@Ivaylo: Octane is a GPU engine; it can't possibly use the 3ds Max API for rendering.

Best regards,

coilbook wrote:all the phoenix objects are obeying the 3ds max specifications and are accessible via 3ds max SDK

This is not true. First of all - you can "access" some objects using standard Max SDK, but just "accessing" them is unusable, 'cause you can't get some special (specific only to those objects) data from those objects without an API for those objects published by dev of these objects. Moreover, you can't even identify those objects properly when iterating through all the scene objects, because you don't have the object's ClassID (or an InterfaceID) published with API for those objects. It can be achieved using reverse-engineering approach, and I said previously that I'll try to overcome the lack of SDK for fume objects using this approach - but this will take more time, and perhaps may have no success...

coilbook wrote:that's why we provide no SDK

Another not true. They do provide an SDK (two header files), we got it together with dev-license for PhoenixFD. And it only contains the API for accessing the simulator object - only allowing to obtain the volume data (smoke, temperature, velocity channels...). No API for the foam object, not ClassID, no InterfaceID, no description, nothing. I need to do my own investigation to get how it works internally and see what data I could get from it and how can it be used by Octane...

Other things are not true too. I just have no time to go through all of them. Octane is an integrated plugin, it has its own "atmosphere support", it uses pre- and post- render events, Octane has its own set of "textures" capable to do what is needed for certain objects (e.g. it does not need any standard or VRay texture nodes to render volumes properly), etc etc...

Don't worry, as I said - I will investigate this issue a little bit later, and will try to reverse-engineer this fume object. If we will have the need - we will ask Chaos Group about some additional info...

JimStar wrote:

coilbook wrote:all the phoenix objects are obeying the 3ds max specifications and are accessible via 3ds max SDK

This is not true. First of all - you can "access" some objects using standard Max SDK, but just "accessing" them is unusable, 'cause you can't get some special (specific only to those objects) data from those objects without an API for those objects published by dev of these objects. Moreover, you can't even identify those objects properly when iterating through all the scene objects, because you don't have the object's ClassID (or an InterfaceID) published with API for those objects. It can be achieved using reverse-engineering approach, and I said previously that I'll try to overcome the lack of SDK for fume objects using this approach - but this will take more time, and perhaps may have no success...

coilbook wrote:that's why we provide no SDK

Another not true. They do provide an SDK (two header files), we got it together with dev-license for PhoenixFD. And it only contains the API for accessing the simulator object - only allowing to obtain the volume data (smoke, temperature, velocity channels...). No API for the foam object, not ClassID, no InterfaceID, no description, nothing. I need to do my own investigation to get how it works internally and see what data I could get from it and how can it be used by Octane...

Other things are not true too. I just have no time to go through all of them. Octane is an integrated plugin, it has its own "atmosphere support", it uses pre- and post- render events, Octane has its own set of "textures" capable to do what is needed for certain objects (e.g. it does not need any standard or VRay texture nodes to render volumes properly), etc etc...

Don't worry, as I said - I will investigate this issue a little bit later, and will try to reverse-engineer this fume object. If we will have the need - we will ask Chaos Group about some additional info...

Thank you for explaining