[REQ] Holy crap, microdisplacement.

[BbB]

My hunch is that our Neo-Zelander man of mystery is about to teach the Maxwell and Fry crews a lesson

[mrCarnivore]

I fear that implementation of MPD is low prio and even if it will be implmented the memory need would be imense. I hope Ono gets his hands on a nice paper whcih explains how to do MPD without a huge memory imprint... Or maybe he can think of a good way himself. *crossing fingers*

[BbB]

Dunno if its low priority or not, but it would certainly be a big milestone, for me at least. Right now, Indigo is pretty much on par, and even more advanced, than its commercial competitors - Maxwell and Fryrender - in a lot of respects except MPD. With swift action, Ono could even beat Maxwell, which has developed but not yet implemented its own system.

[mrCarnivore]

MPD is indeed a very big milestone and is on top of my personal wishlist (right after fixing sss in 0.9 ).

And I even think that it's a must nowadays for a unbiased renderer. Bumpmapping is not really realistic, but cheating, if you think about it!

[CTZn]

I see mpd as secondary, after the lighting/rendering engine (aren't these the same ?). It's not a cheap piece of code (unless it's available in public domain), so it should be approached as a whole, that is, not right now IMHO.

But yeah would be some milestone, along with procedural textures libraries

[BbB]

I must say I disagree. The engine is fine. It basically lets you do anything you like. You've got a point about procedural libraries, but there are already perfectly fine workarounds for these (make a procedural skin in Blender, bake it to texture, et voila!). It's just a little bit more work. But there is no workaround for MPD. Blender displacements won't work in most cases as they result in impossibly huge meshes and still give a coarse result. MPD would let you do things (most likely very nice things), which you simply cannot do right now, no ifs and buts, and which would take Indigo a big, big step further towards the Graal of full photorealism. Now you're right about the difficulty, but that's a different debate and it hasn't stopped Master Ono in the past, has it?

[CTZn]

I totally agree with you, BUT the render engine is still on dev/polishing phase, IMHO again. That's ok to me.

[BbB]

I know what you mean. But I guess every software is a WIP, which gets updated continuously. My benchmark, for better or worse, is the commercial stuff out there, because they have biggish teams and you would expect them to be ahead of our lone rider here. Yet look at Maxwell and Fry renders and you'll see that's not the case. (In fact, I often find Maxwell renders have an unpleasant blurriness to them, which, in my ignorance, I put down to their noise-reduction algorithm). That's true in all but one respect, though, which is MPD. If you look at the latest Fry renders using their new displacement system, you'll see it really does make a huge difference in realism. Hence my comment, basically.

[Kram1032]

I put the blurriness of of Maxwell renders down, to a too low max num consec rejections value, after finally seeing in detail, what it does (Thx CoolColJ )

[Frances]

deleted because it was off-topic

[Kram1032]

I see...
Usually, higher res, means more time - why isn't that the case?

[Frances]

deleted because it was off-topic

[Kram1032]

I see....

[BbB]

Yes, but for me, who needs to produce images that are at least 2400*1800, downsampling is not a solution. Any image that is larger than that will need more than the two gigs you can access in a 32 bit system to compute, even relatively simple ones. So that's a no-no.

[Big Fan]

hmmm I've never tried an image that big
that memory limitation sounds like something that should be put in the tuts for reference/guidance
is 2400x1800 the practical limit for 32 bit then? ..perhaps 2048x1536 or 1920x1200 would be good as recommended maximiums for newbies?