Page 1 of 1

Newbie questions

Posted: Sun Jul 07, 2013 7:04 am
by danclarkwcp
I have quite a few newbie questions, but don't want to hijack the forum boards and wear out my welcome. So, I'll start with a few basic ones. Please note that my background is commercial photography, so my knowledge of 3D modeling and rendering is pretty limited (tho' I'm learning a lot, especially via Jason Maranto's and James Coleman's videos). FYI, I'm planning to use Maxwell Studio, on Mac computers, as I don't have any modeling programs other than the Rhino 5 Mac OSX beta version, which I believe does not work with the Maxwell plugin. I currently have a few quad core i7 iMacs, ranging from 12-32 GB of RAM. I'll use Studio on one of them, then add 3-4 computers as render nodes when it's time to render. I'm guessing most of our renders will be in the 4K x 5K or 5K x 6K range, in order to be a similar size to the files from our medium format digital backs, especially if we're combining photography and rendering. So, now some questions, in no particular order:

- When receiving a file from a client, what things do we need to check right away, to make sure we've gotten a usable file?

- What file formats work best for importing into Studio, and why? Is STL a workable file format for Maxwell? If so, what are the best settings when exporting from SolidWorks? We have received a few STL files from clients, but have had many problems with the curved surfaces not being smooth.

- Speaking of smoothing, how do we know the correct amount of smoothing? Also, how do we undo smoothing? A regular "undo" doesn't seem to work for us, so we have to import the model all over again, then try a different smoothing angle setting.

- For Studio and rendering, what is a good amount of RAM? Is there a way to set how much is being allotted to Studio, how it's being used, and what types of models/materials/textures/render settings increase the RAM requirements? Also, is there any additional info to know about RAM when doing network rendering?

- Imported files never seem to be the correct size, and are usually way too large. Are we doing something wrong, or is that common? Specifically with Rhino to Studio, are there settings in Rhino we need to use so that the size is correct in Studio? We have tried different settings under Rhino's File>Settings>Units, to no avail. If we make a 1 meter primitive cube in Rhino, it doesn't come in that same size in Studio. And then, even after we scale it to the correct size in Studio, it doesn't seem to agree with Studio's grid (it'll be 1 meter according to the Info box, but almost 2 meters according to the grid).

- is there a way to Snap to Ground/Grid in Studio? Seems like that would be very useful.

- When rendering a Region, we can't make a selection right away, it seems to be necessary for it to render to the first SL before we can make a region selection. Any tricks to know, so we don't have to wait?

- We find that Studio crashes a lot, particularly when we make changes (moving camera, object, etc.) in the Viewport while FIRE is rendering. Anyone else having similar problems? Any solutions/suggestions? We are running the most recent version, 2.7.20.

OK, that's probably more than enough for now. Any help/advice/suggestions greatly appreciated.

Thanks in advance,
Dan Clark
www.weinberg-clark.com

Re: Newbie questions

Posted: Sun Jul 07, 2013 6:47 pm
by JDHill
You are correct that there is no plugin for OSX Rhino, as there is not yet an SDK for it. You could use bootcamp (not parallels or any virtualization running on top of OSX, though -- it can work, but it's not supported) and run Rhino on the Windows side, or you can do as you say and use Studio to set up your Maxwell scenes. That aside, I'll try to address your questions:
danclarkwcp wrote:When receiving a file from a client, what things do we need to check right away, to make sure we've gotten a usable file?
I'm not sure if you're referring to a 3DM, or some mesh file that you'll be importing directly into Studio. In the former case, try to look for degenerate geometry that will fail to produce a good mesh (SelBadObjects and What commands can help here), and for good geometry, get a little familiar with Rhino's meshing parameters, if you're not already, so that you are producing good meshes (you'll probably want to go export OBJ > Studio here, since OBJ supports texture coordinates) from your geometry. In the latter, if you receive mesh files, you could accept OBJ or STL, provided they are of decent quality, though it will probably be preferable to get IGES or similar, so you can control meshing yourself by importing into Rhino.
danclarkwcp wrote: What file formats work best for importing into Studio, and why? Is STL a workable file format for Maxwell? If so, what are the best settings when exporting from SolidWorks? We have received a few STL files from clients, but have had many problems with the curved surfaces not being smooth.
OBJ would generally be preferable to STL, though as far as meshes go, STL is probably what you'll get from people using SolidWorks. Regarding smoothness of curvature, that will be up the person meshing the model, and here, SolidWorks provides relatively little control -- it has basically a single "quality" parameter, and will produce STLs which are sub-optimal for certain usages, in particular regarding displacement, since it will tend to produce lots of narrow triangles, and will not subdivide simple planes at all. Again, if possible, it will usually be better to get IGES or similar, and import them into Rhino.
danclarkwcp wrote:Speaking of smoothing, how do we know the correct amount of smoothing? Also, how do we undo smoothing? A regular "undo" doesn't seem to work for us, so we have to import the model all over again, then try a different smoothing angle setting.
This is subjective, and you control it (as I guess you have already found) in Studio in the Object Parameters panel. If you bring in a mesh with no vertex normals, Studio will generate some for you when you tick the Smoothing checkbox and click Recalc -- to undo that, you should not need to undo, as unticking the box will set the object back to using flat normals.
danclarkwcp wrote:For Studio and rendering, what is a good amount of RAM? Is there a way to set how much is being allotted to Studio, how it's being used, and what types of models/materials/textures/render settings increase the RAM requirements? Also, is there any additional info to know about RAM when doing network rendering?
The answer here is, simply, as much as a given model requires, with its geometry and referenced files. There is no explicit control over this -- as much memory as necessary will be used, to the point that you run out, in which case, the model cannot be rendered on the machine in question. Minimizing memory usage consists primarily in the use of instances, the use of textures which are not overly-detailed (just remember that you need no more detail than the camera is capable of perceiving, given the output resolution), avoiding the use of too much or too detailed pretesselated displacement, and not trying to use Maxwell Grass on too large a plane, since that feature can easily exhaust the resources of any given machine if over-used. There would be other factors, but I'd say those are the main ones.
danclarkwcp wrote: Imported files never seem to be the correct size, and are usually way too large. Are we doing something wrong, or is that common? Specifically with Rhino to Studio, are there settings in Rhino we need to use so that the size is correct in Studio? We have tried different settings under Rhino's File>Settings>Units, to no avail. If we make a 1 meter primitive cube in Rhino, it doesn't come in that same size in Studio. And then, even after we scale it to the correct size in Studio, it doesn't seem to agree with Studio's grid (it'll be 1 meter according to the Info box, but almost 2 meters according to the grid).
One unit in an MXS file is equal to one meter, in all cases. So, if you set Units in Rhino to meters, then the scale will match, and not otherwise.
danclarkwcp wrote:is there a way to Snap to Ground/Grid in Studio? Seems like that would be very useful.
It may be useful, but no, there currently is not.
danclarkwcp wrote: When rendering a Region, we can't make a selection right away, it seems to be necessary for it to render to the first SL before we can make a region selection. Any tricks to know, so we don't have to wait?
It seems to work fine here, are you certain you've set the desired camera active in the viewport? Actually, now I read this again, I'm not clear on whether you're referring to Studio or Maxwell Render. So, in Studio, make the desired camera active in the viewport, and select it so that it's parameters are showing in the Camera Parameters panel; you can then set the Selection to Region in the Sensor panel and select your region, before then rendering the scene in Maxwell Render. Otherwise, if you open an MXS in Maxwell Render, you can indeed set a region prior to rendering, though you will basically have to do it by the numbers, since there is not yet any image rectangle in which to select the region (I think this is the scenario you were describing).
danclarkwcp wrote: We find that Studio crashes a lot, particularly when we make changes (moving camera, object, etc.) in the Viewport while FIRE is rendering. Anyone else having similar problems? Any solutions/suggestions? We are running the most recent version, 2.7.20.
Not especially, I guess I'd just try to see if there seems to be some common factor in play -- that a particular texture is being used (in a material, HDRI environment, etc), that a certain material that uses something out of the ordinary like complex IOR, displacement, that a particular render parameter has been set in Render Options, and other things of this nature.

Re: Newbie questions

Posted: Mon Jul 08, 2013 7:49 am
by danclarkwcp
Hi JD -

Thanks for the quick and very in-depth response. Of course, your answers just made me think of more questions, and to realize how much I have to learn. Let me do some more homework, and hopefully my next questions will be more educated ones.

Thanks again,
Dan Clark
www.weinberg-clark.com