Hi,
If I submit a vray standalone job through Monitor there is an option for tiling
Yet in the 3ds Max Submitter there is no option to tile in the workflow for vray export?
Am I missing the option somewhere?
Thanks
Ant
Yet in the 3ds Max Submitter there is no option to tile in the workflow for vray export?
Am I missing the option somewhere?
I think that’s just a workflow feature we haven’t implemented. Considering the SMTD already supports tile rendering, is there a good use case for having the offload job support tiling? The big one I can think of right now is offloading to AWS where you have to pay for Max IO and Windows licenses. Is the lack of tile rendering going to outweigh the cost savings?
Are there other problems I’m not thinking of? We’d have to discuss where this would fit on the dev priorities, so it’ll be good to have the whole picture.
it’s not the DBR offload I’m looking at it’s the export to .vrscene (either locally or on deadline) then render with Vray Standalone Tiled
Currently I can do the export within 3dsMax then open Deadline Monitor and submit that exported job via VRay Standalone with Tiling, but I should be able to do this with SMTD
It’s an often requested option to use the export to vrscene that’s usually thwarted by some windows only plugin. A workaround is of course just to submit a full 3dsMax background job with Vray as the renderer and tile it this way.
Would be nice to have this option, not talking full blown Jigsaw, but at least to match the options from the Monitor submitter.
I’m sure if there are others chiming in it’ll be worth bumping up the list, else it can go onto the big to-do list 
Sounds good to me! We’ll see who else needs the feature.
Keep getting requests for this feature, mainly from large architecture practices looking to get cloud ready and/or just optimize workflow. Do I need them all to respond to this thread? or can I send you a list in an email?
There’s a developer issue for this guy. I suppose… Would those customers be willing to reach out to us so we could track who/how many? It helps strengthen the case for implementing it. They can throw an e-mail at us with this forum thread.
Hi Edwin, that’s something we would be realy keen to have
Regards
Raj
1 Like
Do you find often that using the tile rendering inside the SMTD is problematic? What’s the big gain from sending it off to V-Ray for tile rendering? I’m just trying to build a good case for the dev effort this requires.
It’s large images that are often used with tiling, yes it’s possible to export a V-Ray .vrscene in a 3d application, then open the Deadline Monitor and pick the exported file and then send this to be rendered, but it would be a lot easier if Deadline could handle the export and tiling for standalone from within the SMTD submitter.
There’s a big drive to use linux because of the cost in the cloud, as well as the possibility of the 3d application charging for command line rendering (makes UBL easier too). It’s also seen as better option for rendering as there will be no application memory and cpu footprint.
As Chaos Group are really working to get all applications level in capability it’ll be easier to balance resources across different departments with 3dsMax, Maya, C4D, Rhino, Revit, Sketchup, Houdini, Unreal, Blender etc will all be able to export and render on the same system.
For what it’s worth we’re pushing ahead with a move to VRay Standalone - for basically the reasons that Anthony mentions there, notably Linux render nodes which are beneficial both locally and in the cloud - and we also render tiled too much for this to currently be feasible. Max is the only thing tying us to Windows, and whilst we can’t do anything about that for the clients, our Farm would be so much better if it were Linux only.
That said, we have a custom Deadline submitter so I’ll just implement the feature myself, I just thought I’d throw another voice in the “This is a good feature that people should use” conversation.
2 Likes
Hey Dan. Your name’s a sight for sore eyes! I’m wondering if this pre-covid thread ever gained any traction before I set to customizing a solution.
Hello Sir!
Apologies for the delay and I hope you’re well!
I’m 95% sure I implemented this into Hydragen. I seem to recall there being a discrepancy between how Max/SMTD carved up the tiles (absolute pixel values from a certain corner?) Vs how Draft wanted them (normalised 0.0 - 1.0 float values, possibly from a different corner) which is the main reason I remember doing it at all! Those specifics may be wrong.
I don’t think I got round to implementing jigsaw tiling, though. We never really used it properly IIRC - I think rendering on Linux was one of those “always coming, never arriving” things, like GPU rendering replacing CPU, or demographic shifts leading to a perpetual Democrat supermajority - so I don’t think it was battle tested. But it should work, at least as a starting point.
Dan G!
Super nice to hear back from you!!!
I actually just finished a complete end-to-end solution that covers off the entire pipeline. Yes, discovering the image coordinates were vertically flipped was a pain, but once I understood that to be the reason my assembled images were blank, it was fairly simple to adjust for. There were other areas where I had to map HydraGen attributes to what the V-Ray standalone plugin wanted to deal with natively, but that’s all sorted now. While working on it, the closest analogy I could think of was blindfolded spelunking, or wrestling a tiger covered in thorns.
What made this solution a bit more challenging than a straight HydraGen implementation is that I am forcing any 3dsmax submission to be converted to a .vrscene and rendered out on Linux, while maintaining an unchanged HydraGen submission process from the perspective of the artist.
Anyhow, full automation is all done now, so we have a seamless process where our 3dsmax/V-Ray and HydraGen jobs no longer require Windows to render.
Cheers!
JT