m:studio 2.4d in use on SA Sports Hall of Fame

#161

What version of LW has Metaform Plus?

I was not expecting messiah to handle ngons at all. I just figured I’d give it a shot. My first basic untextured test showed messiah handles ngons, then the texturing freaked out in my watch scene test.

#162

Nice testing by the way, Paul! Metaform Plus has been around since, gosh, version 4 I believe. I remember watching Ron Thornton using it on his video tutorial, Spacecraft Modeling Design years ago. LW 7.5 should have it. If not look for metaform.p in the Plugins>Model folder and add it manually. :slight_smile:

#163

Thanks for the tip Gary :thumbsup: I’ve probably used it before, but since my 3D knowledge works on a need-to-know basis, some rusty bits drop out of memory and then I need to relearn. Man, I sound really old and going down hill, don’t I? :scream:

#164

In the process of optimizing my scene, I switched off TLHPro Occlusion on the watch chrome and my render time on this limited region render went from 18min to 5min. I also dropped diffuse from 0.3 to 0.1 for a less bright silver look and more chrome look. The grain in the grooves in the fg is softshadow needeing AA Level 4 instead of 3.

#165

final_test_06.jpg734x249

9min 42sec
AA Level 4
chrome diffuse dropped from 0.1 to 0.02

I thought this region of interest is cool. I personally love the IOR on the glass bevel and the red 12 o’clock notch reflecting in the push button.

00h50: I’m going to bed now. I’ll put the above render on oversized and then I’ll scale down to get perfect AA and post in the morning.

#166

Very nice Paul, I really like the metal with the low diffusion level - it’s much more realistic. Very nice details all the way around on the watch. Do you plan to make the watch look used or aged, dirty it up a bit - smudges on the glass, scratches, etc…?

Oh, by the way, I looked in my LW7.5 folder, and metaform.p is in the Legacy_Plugins>modeler folder. :slight_smile:

#167

Glad you like it Gary. I’ll keep diffuse nice and low. And yes, I’ll age the watch.

Thanks for going to the trouble getting the plugin info - much appreciated!

My overnight render was too ambitious at 6400x4800, bringing the machine to its knees. So I have nothing to show this morning, sorry.

Are there any ways in messiah of making sure a large render doesn’t need too much RAM and page memory? Or do I simply need more RAM?

#168

When I render High-Res images I use to set ChunkFiles to 33, but be sure to select a Temp dir with a lot of free space!! If you do I’m sure you can render that big image! :thumbsup:

/ Svante

#169

Thanks for tip, Svante :thumbsup: I went and read the docs after your post and now I have many questions :eek:

Is there a rule of thumb on how to compute a roughly ideal Chunk #Files?

For instance, let’s say with 8 Chunk Files messiah is happy to render my 800x600 image. A 6400x4800 image is 64 times the spatial resolution. Should I then specify 64 x 8 = 512 Chunk Files?

After inspecting my designated Chunk File temp folder, I see 427 undeleted chunk files totalling 2GB. Messiah’s docs say that chunk files are deleted after a frame is rendered. Am I correct in assuming these files are remnants of aborted renders? If so, should chunk files not be deleted by messiah even if I cancel a render? Or is it something else?

I see one of the chunk files is 133MB in size. This would mean a total of 1GB worth of chunk files to render 1 frame using 8 files. That’s wild, but if that’s how it is, then I’ll have to be more mindful of disk space allocation.

Does chunkfile size depend on scene content, complexity, rendering methods, lights used, shadows, etc.? If so then determining a good setting is not easy for a user to do. Do you do a thumb-suck and if it crashes you try another setting the next day? Is there no way in which messiah can suggest an ideal #Files according to the given scene and render setting information?

#170

The latest watch render looks muuuuch better with less diffuse! :thumbsup:
And it also fits much better with the other stuff.

I would desaturate the blue hands a bit or make them more contrasted to the background. They could also have a white line in the center, looking like a night-glowing-thing.

You can easily spare the Occlusion in this case - nobody will notice it anyway.

I would reduce the reflection on the glass, or even better, use a much less busy HDRI or an extremely blurred one. This kind of thing looks best with only slow gradients for reflection (I currently have to visualize a watch too :wink: )

I have no real opinion about the background checker… :shrug:
But I don’t miss anything without it :wink:

Chunk files are a multi bladed sword:
For small renders, I use Ram Chunks anyway, since this is faster and doesn’t clutter the temp directory (yes, messiah should delete or overwrite those files, but it seems it doesn’t).

The Chunks are very large since (I assume here) they are uncompressed floating point with all the data conserved (diffuse, specular…). So for large renders, I would make sure you have lots of space on the drive (10 Gig ++).

I wouldn’t think it makes sense to have thousands of chunks. The highest I ever used was 128 of them. But be careful: After the rendering, messiah has to load all the chunks back to write them to disk in one continuous file. I once tried to render the AoN Spiral image in high rez: everything rendered fine, but then messiah wasn’t able to save the file because of not enough memory and crashed. The image rendered about 17 hours which were lost although all the chunks were there…
While this is as stupid as it can get, funny enough Mental Ray has EXACTLY the same problem - you can render heavy scenes and even rather large images, but if the image is too large, MR will just tell you after hours that there is not enough memory to save the result… :banghead:
Well, for Mental Ray there is a workaround, for messiah I know none.

Chunk files save the result of the render in parts, so there isn’t much voodoo about them AFAIK. I never tested it, but I would guess that an empty scene creates chunks almost as large as a busy one.
So I would guess (once more - messiah is all about guessing and believing :rolleyes: ) that you can use as little chunks as you want as long as they fit into memory (= messiah doesn’t crash). The image data is only part of the stuff messiah has to keep in Ram, so chunks can ease the pain but not remove it.

The other thing that chunks improve is load balancing. With two processors and only two chunks and threads, it is possible that for instance the lower one takes quite long and the upper one sees just background. Then the second CPU is sitting idle after not too long. Splitting the frame into 8 slices/chunks or more will balance this automatically much better (although not as good as Cinema 4d which starts with two chunks and if one of them is finished earlier, it splits the remains in two again until everything is finished. The best and simplest approach I’ve seen so far.

But upgrading to 2 Gig is always worth it anyway. Cheap nowadays and more isn’t going to help much without 64 Bit versions…

So, on the endless list of improvements there would be entries added for:

  • 64 Bit messiah.
  • Stop and continue renderings on a chunkwise basis.
  • A way to reconstruct an image from finished chunkfiles. Or a little app that is able to compile them into something usable.
  • Finding a way to write images in a “streaming” manner, so that writing the file doesn’t need as much memory.
  • messiah knowing beforehand how much memory it will need (should be possible to compute close enough) so you don’t waste time with rendering something that can’t be saved afterwards.
  • An render progress and image viewer that is worth the name. Keeps several images available to see differences (like in Lighwave), allows to save previews after rendering, shows in-depth-render information while and after rendering, allows to view the image scaled down while rendering…

Cheers, :bowdown:

#171

Watch scene, 800x600, no AA, limited region on, frame 225
8 x 7266KB chunks files named _chunk000_b8c to _chunk007_b8c
files not deleted after render

Watch scene, 800x600, AA Level 3, limited region on, frame 225
8 x 7266KB chunks files named _chunk000_b8c to _chunk007_b8c
files not deleted after render

Watch scene, 800x600, no AA, limited region on, frame 227
8 x 7266KB chunks files named _chunk000_b8c to _chunk007_b8c
files not deleted after render
observation: a set of chunk files get overwritten by the next frame and not deleted

Clear scene and load simple object.

Simple scene, 800x600, no AA, limited region on, frame 0
8 x 7266KB chunks files named _chunk000_b8c to _chunk007_b8c
files not deleted after render
observation: loading a new scene still uses same chunk file name

close and reopen messiah and load simple object

previous chunk files remain undeleted
a new series of 8 chunk files created _chunk000_ab8 to _chunk000_ab8
observation: chunkfile naming seems to change when restarting messiah

scene complexity does not influence chunk size

now to test resolution . . .

400x300 generates 8 chunk files 1793KB in size
8 x 1793KB = 14688256bytes / (400x300) = 122.4 bytes per pixel

800x600 generates 8 chunk files 7266KB in size
8 x 7266KB = 59523072bytes / (800x600) = 124 bytes per pixel

1600x1200 generates 8 chunk files 29063KB in size
8 x 29063KB = 238084096bytes / (1600x1200) = 124 bytes per pixel

let’s say I want to render 6400x4800 like I tried through the night
that’s 30,720,000 pixels x 124 bytes
= 3809280000bytes required for chunk files
= 3.55GB disk space required

This seems to be an easy calculation which messiah can make for the user, at least to tell you BEFORE rendering that there’s not enough disk space in the temp folder. Perhaps just a red warning button comes on the Render GUI to show the problem.

#172

Cool you did the actual testing!

Yeah, exactly this kind of “make my life easier” things are badly missing in messiah in a lot of places. Too bad that the team is so small and has so many fires to extinguish…

Well, can’t be helped.

Cheers,

#173

This is getting deep - I’m quoting myself :scream:

With 3.55GB of chunk files, what kind of RAM would be required for messiah to output the final rendered image?

Is this the solution to the above problem, Thomas?

#174

In this case the fastest answer is testing it :wink:
Render a black frame in that size and watch Taskmanager.

No, streaming isn’t a real solution, the only solution is 64 bit and lots of memory.
Everything else is just working around the core problem.
Sure it could ease the pain, but it is only possible with certain formats under certain circumstances…

It is all rather moot points anyway, since there is so much to do for pmG that exotic things like this are rather far down the list I guess…

Cheers,

#175

render test of the same scene, same frame
720x576
2 threadsRAM chunks #Files = 1
11min 19sec render time

Disk chunks #Files = 8
8min 08sec render time

RAM chunks #Files = 8
8min 13sec render time

DISK chunks #Files = 2
9min 46sec render time

DISK chunks #Files = 20
8min 24sec render time
With 2 threads specified, 1 chunk forces messiah to render with one thread, the other one idle, system running at only 56% CPU usage.

2 Threads and 2 chunks spreads the load, but the top half of the scene has all the chrome, so the one thread sits idle waiting for thread 2 to complete. This is the load balancing which Thomas spoke of.

Too many chunks carry extra time delay overhead.

#176

Hm, but that is a rather bad result for two CPUs I think. I would have hoped it is closer to half the time with 2 CPUs.

Weird that RAM chunks are slower for you - writing to disk should be slower normally…
But that timer is quite inaccurate - may be just random.

Cool tests - mostly hardens my “feelings” and “guesses” :wink:

Cheers,

#177

That’s why I did these tests, just so that I may know for myself how to set this up for final render.

I’m running a single CPU with hyperthreading and that shows up as 2 CPU’s in my performance monitor. RAM may be slower on my machine because I’m pushing the limits of my RAM and then I’m paging to disk anyway. Not ideal, but still gives a fair idea. If I render with 1 thread on my system, then 1 CPU is inactive and the total performance is 56%.

I’m sure these tests will favour RAM chunks if I had 2GB.

Anyway, these tests do support the messiah docs which say that there’s very small performance difference between RAM and DISK chunks. And using excessive DISK chunks makes the slower disk access overhead that more evident.

#178

My current HDRI is not that busy. What you see reflecting in the glass is the photo mounted against the wall above the watch. I don’t mind the reflections that much since I intend flying the camera through the glass low over the watch face. Then all the face details should be crystal clear… Thanks for the comments :thumbsup:

#179

Would be cool if a Limited Region render did not allocate chunk files for the whole image, but only for the region being rendered. In that way one could render and stitch tiles of the final image in a compositor. Rendering vastly large images would then be possible.

#180

Ah - Hyperthreading - that is no real 2 cpus anyway, just faked. In that case the difference is rather astonishingly good. I didn’t get much of a difference with one or two “cpus” on my hyperthreading machine. The Taskmanager is outright lying on such machines.

The limited region is the same in Lightwave and Mental Ray - all allocating memory for the full image.
But in XSI there is a cool method of rendering in tiles without moving the camera or allocating unneeded memory. I recently rendered a 16000x9000 pixel image in 4 such tiles there. Rather impressive :slight_smile:

Cheers :thumbsup: