Hi,

I dabbled in CG during the Discreet days with 3dsmax and such, but I was never a programmer and I'm pretty out of my depth these days and thought a game dev forum would be a good place to start looking for some help given how far 3d graphics and performance have come. I was wondering if anyone could point me in the right direction regarding a project I'm working on.

The gist of what I'm trying to do is take input data from a file, use that data to deform some already-built geometry (imagine I have all the vertex position data in a file), and then render a single frame of this geometry with appropriate lighting etc. It's really not for a game and it's supposed to be an automated process that can be run at any given time, over and over, often many instances running at the same time.I know I could manually do this in something like 3dsmax, but it needs to be a hands-off, command-line sort of thing. I also don't need any sort of photorealistic rendering or complex effects. In fact, I already have it rendering in a somewhat automated way using Apple's Scenekit, but I need this to run on a server, not an iPhone.

A further note -- I'm looking for someone who could build/set-up something like this! (freelance)

Any suggestions or input you could provide would be a great help, and if I posted this in the wrong forum, please feel free to move it! Heck, if there is a better community in general for this sort of thing, that would be great to know too.

Thanks!

Render farms are quite standard stuff in terms of servers. https://en.wikipedia.org/wiki/Render_farm

@wedouglas Depending on your actual requirements, this sounds like a look candidate for a cloud based set up, although the complexity would be how to get a GPU enabled worker to pick up the message request off the queue. I can see 3 models:

1. You spawn up a GPU enabled worker each time you need something processed.
2. You leave one permanently running
3. You use 'serverless' computing - although I've never seen that available with access to a GPU.

Problem with any of these is that #1 requires more orchestration (maybe the serverless component could enable that machine) , #2 requires a fairly expensive VM to run, #3 - don't have a clue if anyone offers this.

Sorry to not be more helpful. 

One thing which might work, I have no idea about the use of 3dsmax, is having that on your cloud machine if you can write a macro for it? Might work.

On 9/18/2018 at 10:59 AM, wedouglas said:

command-line sort of thing.

I've done something like this with blender: Users put pictures in a folder, click a bat file, blender renders images. (The pictures just replaced textures and proper filenames were required, but worth to check out how much more you can do using command line.)

I've also made a server side tool that checked new files in a public folder and rendered 3D product package previews using a software renderer. Maybe this would be fast enough even when written in PHP and no GPU is required.

I've already worked on multiple projects like this in past (partially on the university and then during my career - I can share some details).

One of them had models exported in a specific format and executed a batch file which sent the scene to the server, where automated job picked it up in a sequence and pre-processed (e.g. building Split-BVH mainly). It wasn't a cloud though, just dedicated server with GPU rendering. Originally we thought of using MaxScript but in the end decided against it - interchange format like Collada or FBX is by far better, simply because some artists in the group preferred different tools. After having the scene processed, users could send requests with camera definition and received an image back (with quality settings).

Another one was just a post-script in MaxScript that performed a render with specific parameters. After that, the image was taken and processed (from within the maxscript) with special software that performed advanced de-noising. And stored results, which were presented to the user in a new window. This wasn't done on separate server, but as a new process spawned from within the maxscript. Side note, MaxScript is quite tricky and may be a bit slow - I personally don't like it, but as per client requests we had to use it to interact directly with 3ds Max software.

And another one was for simple product image generation - model and textures were updated with script from specific folder to server, which returned a sequence of images (from viewpoints around the object). This was running a service on dedicated server which we were communicating. Again, using GPU based rendering and throwing a sequence back directly was acceptable solution.

...

In short: In general if you have a server processing requests like this, you need to consider that you need to (at least):

• Have a way to send requests (custom software/scripts - most of the time we used a custom software, that connected to the server and sent all necessary data ~ e.g. the scene (with all textures) and the command, possibly only the command when the scene was already prepared there), the software also waited for the response with results which were later presented to user.
   
• Have a way to process requests on server-side (job like software that will have a queue of received requests and spawn process for each one that was received, for the finished ones it sends back the results). This one is technically just a "queue" and "dispatcher". However you have to think off how to get results back to the requester.
   
• Rendering software (spawned as the process from server-side job). In our case this was a custom GPU-accelerated path tracer - which took me most of the time, and was the piece of software that was doing the actual rendering.

There are possibilities of fusing the rendering software into server-side job, or doing other changes in the design. I did it for two of the above cases this way, as it was good enough for what was required in the end (which is by far the most important thing - that your solution will solve the problem). Bear in mind though, that each of this may take quite a lot of time to design & implement - and that of course there are multiple ways how to improve further on (if and when necessary).

In the end, one of the most challenging tasks was to make it easy enough for the actual artists to use (they won't write command line arguments or such), they need it simple enough to setup, with settings they do understand!

...

If you have any questions on details, feel free to ask.