How do you manage complex scenes in SuperPhysical?
In the girlpower patches, Cons nodes are used to add different objects to the scene, their properties, their materials…
Not really convenient when you start to use more than five objects, and you need to manipulate them, spread them, or making them dynamic…
The standard way of manipulating models in DX9/DX11 (Geometry and Transform to Shader to Group) seems to be more convenient (or maybe i’m missing something?)
We can reproduce this way of working in SuperPhysical (duplicating the SuperPhysical module, and pluging each model into it’s own SuperPhysical module)
But in this case, we loose all the interactions between models (shadows…).
So my question is, have you an idea of an easy workflow to work with SuperPhysical and multiple models??
By the way, thank you MrBurk for this incredible contribution, this is beautiful!
Hi,
you absolutely have a point here.
This contribution was not designed to handle large scenes.
I think having a lot of different instances of the shader doesn’t really make sense, still the lighting of a scene should be the same for every object and there would be too much redundancy.
What would really be needed is some kind of material and file browser. Someone at NODE suggested to maybe use message for that.
In the next update everything will be a bit more streamlined and I will reduce the amount of modules and links as much as possible. So this should improve the situation a bit, but for now we are stuck in spreading hell, when handling large scenes.
I’m thinking about the best way to create a basic file manager for SuperPhysical.
First thoughts:
Import a model in a subpatch called like “ImportModel” (one subpatch per model, easier to manage the settings for each model)
automatically put the textures associated to the model at the right place, based on their names (Model1_Normal.jpg → Normal…)
beside of each model, all settings accessible in one place for this model only (Roughness level, SSS level, bump level…)
if the model is spreaded (by a Transform or any other parameter), all other parameters have to be spreaded too, to keep the same number of slices for each parameters, and avoid shifts in SuperPhysical.
“collect” each slice in a list/spread (one spread per parameter), to feed the SuperPhysical shader.
Feel free to add it to the contrib if you think it’s useful and not too buggy (Not tested so much.)
It could be simplified and optimized.
For my personal use, it’s more convenient compared to the system used in the original contribution.
But this draft FileManager should be improved into a cool UI, for the moment it’s not really user friendly…
How it works:
Duplicate Object_1.v4p (located in folder SuperPhysicalFileManager_Objects)
Rename it Object_NewName.v4p (Object_ is important)
Create a subfolder Object_NewName Assets
Put everything in this subfolder (3d model, textures)
If textures names contain a material name (albedo, normal, roughness, metallic, ao), it will be automatically linked to the geometry. If not, you have to do it manualy.
Drag and drop Object_NewName.v4p into SuperPhysicalFileManager, next to Object_1
Click AutoUpdate
Now you have controls for each object (Transform, Materials…) in their respective subpatchs
Wow…you really put some effort into this. Seems like a nice addition to the contribution. I will see how I will integrate this with the next bugfix release of SuperPhysical. Maybe this should be a separate download because the example assets are getting a bit big now, but let’s see. Anyway, cheers!
Also one more thing: The FileManager needs a lot of ticks, but it can be deevaluated as soon as all the Objects are loaded, as all the data is held by the pipeline.
Yes you’re right, the FileManager is very expensive in terms of ticks…
Could be deevaluated easily, but sometimes you need to animate some parameters (this is my case).
That’s why I think it’s not a good solution for SuperPhysical, just a workaround for my short terms needs!
Basicaly, there is two main concepts in this patch:
“dynamic concatenation” (each parameter from each object is concatenated into one spread per parameter, and sent to the shader)
“parallel spreading” (if one parameter from one object is spreaded, all the parameters from this object are spreaded)
For these two very simple concepts, my workaround used hundred of nodes, dozen of subpatchs, and is very CPU expensive (and more object in the scene, more expensive it will be).
I’m quite sure there is far more elegant solutions (maybe involving some missing nodes like ConsS/ConsR ?)
