Solid sphere mode for PHXFoam Particle Shader

[TubeSmokeGuy]

Hi!

I think it would be nice if you could add a "Solid sphere mode" to the PHXFoamParticleShader.
With just a radius parameter, diffuse color (with map slot), a simple specular highlight and simple environment map support (without raytraced reflections / refractions), opacity (alpha) and emission (self illumination).
All in all this should render much faster than the bubble, cellular, splashes mode and could be used really good f.e.to render simple whitewater effects.

Maybe a VRay interface would be good to apply custom materials to that spheres, then the properties of the built-in shading parameters become ignored or overwritten.

Greetings!

[georgi.zhekov]

Hey,

Currently you can use the V-Ray Instancer and instance spheres over the Phoenix particles. Using this approach you can assign a V-Ray material to the spheres and have access to all of the shader options.

Cheers!

[TubeSmokeGuy]

Hi!

Yes I know about that solution and this is no urgent case. VRay Instancer is a good working tool - unfortunatly it has no connection to particle color comming from color or RGB channels of a cached particle stream. Maybe VRay should update its "VRayParticleTex" to grab colors from any particle source to use with the instancer. PHXFoam particle shader has the connection to particles color by the PhoenixFDParticleTexture and so the spheres could become their color i thought.
I just thought it will be good to have this as an option. I don't like it so much to have functions and features spreaded over multiple nodes, tools and objects. Better to have it concentraed in one node. And I think ParticleShader would be a good place.

[Ivaylo Katev]

how about instancer+PhoenixFDParticleTexture?

[TubeSmokeGuy]

Hi! Yes that works. But it works just in the specific case, when the particle sequence which is picked in the instancer comes directly from the PHX simulator or a PRT sequence which exactly matches the simulators particles (exported by PHX PRT exporter and loaded with PHX PRT Reader). In both cases the simulator has to be linked in the PhoenixFDParticleTexture to access the RGB particle channel, cause other particle systems can actually not provide color channels to PhoenixFDParticleTexture.

So particles which come from other sources to VRayInstancer are actually not colorizable by PhoenixFDParticleTexture in a correct manner. And it seems like there is actually no working way to achieve that, please see also https://forums.chaosgroup.com/forum/...particle-color .

[Ivaylo Katev]

"So particles which come from other sources to VRayInstancer are actually not colorizable by PhoenixFDParticleTexture in a correct manner."
If they are not colorized properly in PhoenixFDParticleTexture they would be not colorized properly in the desired solid mode either.

[TubeSmokeGuy]

Yeah, but color channels are a very basic thing in nearly all partilce processing systems. Actually PhoenixFDParticleTexture is not able to read color channels from other sources than PHXSimulatorParticles as mentioned here by Georgi and Svetlin https://forums.chaosgroup.com/forum/...articletexture .
So if this is implemented or fixed, your suggested way to shade a VRayInstancer by PhoenixFDParticleTexture would work for any particle stream which has a color channel. So it would then work in the desired solid mode either.

Edit: BUT I think this is a thing which VRay has to implement too, because VRayInstancer is a node that comes with VRay and there should be a way to shade it with tools provided by VRay. Just reading color values of a paticle stream and redirect them to the instacer instances ... nothing more .

[Svetlin.Nikolov]

Ah, okay, so you gotta know that not all particle systems are equal. Phoenix has to explicitly implement support for certain kinds of particles, especially when it comes to colors.

We are working on some improvements to the VRayProxy that are related, but in the case where you can't read the particle RGB, it sounds like something different. Are you using a Particle Texture, reading from a Krakatoa PRTLoader? Which Phoenix version do you have?

[Svetlin.Nikolov]

Ah, sorry, just now I saw your latest post. So PRTLoader + Particle Texture it is indeed.

color channels are a very basic thing in nearly all partilce processing systems.

The problem with color channels in 3ds Max is that it does not know what particle color is. Max has standard channels for particle positions, velocities, orientations, ages, IDs, but it does not have colors, so every plugin figures out what to do with these in its own way. This is why with colors, each plugin has to implement support for each other particle system plugin's colors...

[TubeSmokeGuy]

To make it clear, I don't have a problem actually. In this thread I just wanted to express the whish (Whishlist forum) for a solid sphere mode for the PHXFoamParticleShader.
Because I think that this could be a way to render some whitewater effects a lot faster than the actual "splashes / bubble / cellular" - modes, which are tracing reflections and refractions. Point mode is not an option, cause the points are measured in Pixels, so it comes to ugly optical scaling when shoot from cameras wich cross huge distances. To colorize these solid spheres with the color or rgb data from the picked particle source is another thing that would be a cool feature on top.

And cause you asked, I dont't want to limit it to Krakatoa. Reading color data from particle streams should be possible for every particle source which is pickable in PHXFoamPaticleShader.

We still got PHX 3 latest nightly, but even there the PHXFoamParticleShader has the mapping slot for color and the option to use a PHXFDParticleTexture to shade the particles with the colors of the particle streams color data channel. I just tried it and experienced the limitations which I expressed in this other thread here https://forums.chaosgroup.com/forum/...articletexture .

I don't need a solution yet urgently. I just wanted to draw your attention to it.


And in general I am not a big fan of all the incompatibiltys between the particle and fluid processing tools which limit the FX workflows in 3dsmax so hard. I think it should go more hand in hand - but thats nothing you have to deal with directly.

[TubeSmokeGuy]

Ah, sorry, just now I saw your latest post. So PRTLoader + Particle Texture it is indeed.



The problem with color channels in 3ds Max is that it does not know what particle color is. Max has standard channels for particle positions, velocities, orientations, ages, IDs, but it does not have colors, so every plugin figures out what to do with these in its own way. This is why with colors, each plugin has to implement support for each other particle system plugin's colors...

I'am not a developer. So please be kind to me if I'am wrong.

For me it seems like that at base all particle caches are data tables. The columns are the channels and the rows are the channel values. So for color you just have to parse the columns for some known names like: color, RGB, vertex color, MXSVector, density, emission, etc. In most cases these values come as point3 vectors which can be normalized and converted to RGB color values.

But as I said I don't really know what I'm talking about. So maybe Im totally worng.

EEEEDDDIIITTTT:
What could be a solution is when you implement some kind of "expert mode" for the PHXFDParticleTexture, where the user has unfiltered access to all data channels the particle cache or particle system provides and it's up to the user to choose the channel and enter a proper normalize range to get working color data. So you don't have to hard code any case.

[Svetlin.Nikolov]

Ah, I'm afraid there is more to this Think of it this way - 3ds Max provides a "standard" particle interface. It has the positions, velocities etc I listed, without RGB, and when a plugin implements that particle interface, it could pass and read data from plugins that someone would write even 10 years later - it's a standard way to pass data and a plugin does not have to know about which plugin the data comes from or goes to at all. However, in Maya for example, there is no such interface. So e.g. Phoenix has to specifically know that there is this think Krakatoa, we have to talk to the devs and work together to make data flow between the two plugins. And if another plugin comes, Phoenix needs to specifically make things happen with it, and Krakatoa have to explicitly make things happen with it as well.

And knowing this - all is fine in Max as long as there is no mention of RGB/Color Since Max devs have forgotten about it, plugins can pass all other kinds of data without worrying about what plugin is on the other side, but with RGB it's the Maya kind of way. We gotta use the thinkingParticles SDK to read their colors, Thinkbox have to use the Phoenix SDK to read ours, and it escalates.

So this is why in Max for most pairs of plugins, positions, velocities, etc "should" pass easily, but for colors we gotta know which exact plugin is on the other side, because each plugin has its own completely unique way of asking about its data ... The wonders of software and a small part of the answer to the question "why everything happens SO SLOWLY"

[TubeSmokeGuy]

Okay. Just for your interest a similar discussion I got with Tyson who's developing tyFlow here: http://forum.tyflow.com/thread-1649.html

One sentence he wrote catched my attention:
Quote of tyson:
" ... It stores colors in particle map channel 0, which is 3ds Max's default vertex color map channel...or you can specify whatever channel you like. ... "

The words: 3dsmax, Default, Color and Channel ... so maybe there is a standard?

But I don't know .

AAAAAND please don't forget to think about the solid sphere mode, which I requested intentionally.

[Svetlin.Nikolov]

Yes, but everyone has to comply with it in order to be a true standard