Messiah render speed comparison.


#81

well i guess im not done playing with settings on this scene then. Lets see how far the shadows can be pushed (afterall there is still 2 minutes to play with to match time with kray)

To me, the biggest problem is the sloppy AA on the reflections, in the Car WIP that im working on, its also showing up as noise when reflecting HDR.


#82

Forget Hybrid, Photon Mapping with no GI Noise Reduction looks the favourite. Still a bit blotchy, but at least we’re now getting a contact shadow under the larger sphere and it only too 6min01sec to render at 600x600 :slight_smile:


Just keep in mind that when you increase the photon count, or change the gather count, you’ll need to tweak the GI Intensity


#83

interesting. the ceiling is horrible but nice to see the settings though :slight_smile:


#84

some tests. This is what I haver so far. Very hard to maintain details(corners). I have try also with hybrid witout success.


#85

the project file.


#86
  • What’s happening in the TOP image, and why is it so washed out?
  • The bottom one looks pretty blotchy, and appears to lack some contrast and even true GI effect. The lighting appears to be constant, instead of emanating entirely through the entrance (or window…?) – It looks more like constant Ambient illumination rather than GI.
  • Finally, it is very hard to tell what the render times and what your current settings are for the test that you’ve made as for some reason, your image is getting distorted.

Cheers.


#87

If the light emitting the photons is outside the mesh shining in, then the mesh needs to have double-sided turned on. Afaik, photons will only ’ hit ’ a polygon that has it’s normal facing the photon. In Labuzz’s image, the mesh was single-sided, which meant that the photons passed through the right-side wall, and then started bouncing around when they hit the floor / left wall poly normals.


#88

so i just did some more tests and confirmed that the anomalies seen in the renders:

  • Dark back wall
  • Weird shapes reflected in the cubes

are all caused by GI Noise Reduction. As soon as i disable it, the lighting behaves normally.


#89

Maybe this is somehow connected with the Bug that gives you very weird results when you render scenes with GI Noise Reduction where the background can be seen?
I got everything from weird colours, dark lines on the horizon to awkward stripes on the groundplane etc. when using this combination.
Those problems combined with the fact that the current GI Noise Reduction eliminates almost exactly those details one looks for when using GI, kept me from using it completely.
I think something more adaptive would be cool, so that large plain areas get less photons/more smoothing and small things and corners get more photons and less blur.

With the current GI Noise Reduction (besides the Bugs) you would have to use an Ambient Occlusion shader on top of GI to get some detail back.

In the end, I always have fallen back to pure Monte Carlo with no GI-NR since I still like it’s look the most. And I prefer reliability over speed. Photons always tend to flicker in animation anyway…
Almost all images in the AoN docs are rendered that way.

Cheers,


#90

It’s more when using Monte Carlo + GI Noise Reduction, as GI NR can be used with Hybrid without getting the above the render errors.


#91

oh yeah, one thing that is really bothering me is the render time BS.

Can someone explain to me how the time is calculated?

I just did a render that claims it took 3:12, but i timed it separatelly and with GI pass its 5:50.

Why? is there a reson behind this?


#92

An Adaptive NR method would be very welcome. In most of the Kray scenes I’ve been playing around in M:S with, you need a gather radius of around 0.1 - 0.5 to get any kind of detail in edges, under small objects, etc… Unfortunately M:S just can’t seem to emit enough photons to allow this size of radius along with no blotches present in the final render - above 16,000,000 photons and M:S vanishes from my desktop.

Glad to see you’re still hanging around out here Thomas :slight_smile:


#93

The final render time ignores the time taken to emit the photons on the first pass, although the timer in the corner of therender window does seem to display the proper render time. That is until it finishes rendering, when it then changes to match what appears in the command line,


#94

what timer? the only timer i see is the commmand line.

also, what is the reason for omitting the photon emission???

mind boggling if you ask me. actually shady and not very respectable.

lol @ shady. pun not intended.

messiah needs to focus its shadiness on the shadows rather then the timer (seriously WTF).


#95

When your preview mode is set to 'viewport ', there’s an ’ elapsed time ’ displayed in the bottom left corner. Ideally this should be displayed in the command line as well, especially in window / text mode, along with the render engine ’ telling ’ you what it’s doing - emitting photons, calculating displacements, rendering, etc…

No idea, probably just an oversight and not intentional.


#96

Ive been playing also with this scene and have gotten some good results, though yes time is very long on renders.

I managed to get rid of some of the shadow, and reflection speckles off via upping the AA samples over 8. I figured maybe we could do a low pass, and rub them out via AA.

another thing though ive been trying to bring the render time down via the radius and photon gather count, but as soon as i dont get the results im looking for I change settings and render. Now this is the part I hate if photons get emmitted and i didnt change that setting why do they have to get emmitted again?
Is there no photon caching option, so we wont have to wait for photon emmisions again, and again, and again.?.? LOL

:wink:


#97

Nope, there isn’t such a thing as caching in messiah - neither photons nor shadowmaps etc.

Makes you dream of something like this:
http://max.is-a-geek.com/Maxwell/ml.rar
While maxwell must be one of the slowest render options out there, powerful post-controls like this make “speed” a quite relative term… Especially for stills.
If this is taken further, you can shoot off a render with just basic settings overnight and then adjust brightness, light balance, which lights to use and maybe later on colour etc. in the morning…
And since maxwell allows for resuming a render you are very flexible with doing so.

Holy shit - we didn’t even scratch the surface yet of what the future will bring in this area.

Best regards,


#98

well so far my experimentations highlighted great power in the renderer and also exposed some glaring flaws. I REALLY hope there is something coming out soon. and i mean SOON. with lw9, i sense a lack of attention towards messiah…


#99

Yes, that is my concern too, but not as much limited to LW9:
When messiah:render was first announced at Siggraph 2000 (if I remember correctly), there was a big need for better renderers. The big packages internal renderers were not very exciting back then…(I think there was even an option announced to buy messiah:render as a standalone renderer)
But pmG wasn’t the only company who smelled that at the time. Today we have Brazil, Vray, Final Render, Turtle and dozens of other renderers from free to expensive. Many of them are quite mature as of now and well integrated into the big packages.

When I did my first own render tests in early 2002 with the so called “advance” edition of messiah (some kind of open beta) for an article in a german CG-magazine, I came basically to the same conclusion as you have come to in 2006.
One of the results (The BeeMan is a model from Christophe Desse):

Heck, I saw great opportunities for messiah in architecture back then, since it did eat even big scenes in a fraction of the time LW needed… :shrug:

I would never have guessed, that journey would take that long.

Today I don’t see a market for a renderer anymore. Maybe it can survive in it’s niche as a character tool if some quite good, easy-to-dress and fast-to-render hair is added, but other than that?

How long can a tool be “promising”?

Cheers,


#100

we are about to find out.