Fstorm render mask id feature request

Hello, I am just testing out the wonderful features of the scene manager. We are having quite a big project right now, which is composed of hundreds of images of furniture. Each element has to be rendered with embedded alpha and in a specific material. You currently have the “render mask on” option from the fstorm scene properties, which is superb. It will be insanely productive for us if you can furthermore add a selection of object id to render. That will enable us to not override render settings and manually enter every time which ID to render.
preview - https://prnt.sc/199wb81

Hi,

Sure no problem, we will add this to the list of requests and most likely we can implement it in the upcoming version.

Regards,
Peter

Hello Peter, Thank you!
If I may add another suggestion that is really useful when doing production images. Probably your tools are more architecturally orientated, but production render jobs will benefit greatly if this has a simple solution.
When a job is added to the render manager if it has different sets the job is exported as a separate scene, and also when rendering every time assets are loaded and unloaded from memory, as it is a totally new job. For several images, this may be okay, but sometimes in production rendering, there are hundreds of passes to be rendered and for every single one the scene has to be totally reloaded. We are using deadline for quite some time and has experience with other managers. At this point, I don’t see a clear integration with it. As you have a tool for this also (which I am currently testing) it will greatly benefit if it has some sort of mode, where it uses just one scene (does not create dublicats) and can perform the batch render straight out of that single scene. As it is in your scene manager.
And lastly, if you can implement the RT mode it will be superb. I am not sure how many fstorm users are currently implementing your tool, as we are not the vast majority, but in some cases, vray users (we work with it also in our arhviz jobs) may benefit from such mode. On deadline, there are a couple of options - such as “force workstation mode”.
I saw another topic about material changing and your proposition for an animation workaround. This is what I am currently using and is clever as a solution, but has its downsides. For instance, naming is an issue, as you need a clear naming convention (material let’s say) and not just a frame number. Afterwards, you have to go and batch rename everything and the process gets complicated.
If those can be implemented we will definitely be using you in our pipeline. You have wonderful ideas embedded in the software. Keep up the good work
p.s. Sorry for the long post:(

Best,
A

Hi Angel,

Thanks for the detailed explanation. There is a clear need for the solution that you are proposing and we already had internal discussions about it. I’m not 100% that it will be implemented in the next Render Manager update but for sure we are thinking about it.

Essentially what we will do is create one job from a file where each task will represent a Scene Manager setup, which will greatly improve the submission speed and you will only have one file open time per node.

The “problem” with FStorm and this special setup is that it will still load and unload the scene from the GPU because with each Scene Manager we are changing things and the render has to stop. With normal animations this won’t be an issue anymore with Render Manager 2.0 where we’ll introduce the “packed tasks” feature where one render node will render multiple frames without stopping between them.

Regarding the RT mode, last time I checked it was not possible to control the interactive. We need the ability to start and stop it, get some stat feedback about pass count or noise level and once the goal is reached we will have to save the image, switch the scene and continue. I’ll have to check again and see what is possible with maxscript.

Anyway I suggest you guys stick around and follow the announcements because awesome things are coming.

Best,
Peter