|
Description
Blender is in need of Render-time (renderer integrated) MicroPoly or Subpixel Displacement. Seeing that 2.46 will support 32-bit floating point maps for use with the Displace Modifier, it is almost essential that Render-time MicroPoly or SubPixel Displacement be an option with no dependency on the Displace Modifier. Look into Mental Ray's or Vray's* implementation.
Attachments
No attachments.
Duplicates
Comments
 Handydan (Blenderstorm admin) wrote on the 13 Apr 08 at 11:56
| |
Kai Kostack is working on it, http://blenderartists.org/forum/showthread.php?t=119216
|
|
smokebox46and2 wrote on the 13 Apr 08 at 16:11
|
here's what Broken (another developer here) had to say about this script you're referring to. i have to agree with Broken.
"Heya, that's really cool! It's not what's usually referred to by micropoly rendering, rather it's a form of adaptive subdivision, which is still very cool, and would be a great addition. I've also seen in other apps, the ability to subdivide not just based on the distance to the camera, but also based on the detail in the displacement map. i.e. large areas of solid colours won't get subdivided much, but areas of high contrast will..."
this script is still useful as an LOD(level of detail)-type function, but is not the micropoly displacement i'm requesting. The subdivision i'm referring to occurs at render-time, within the renderer based on details provided by a displacement map. check out this thread.
http://209.132.96.165/zbc/showthread.php?t=20310
|
|
smokebox46and2 wrote on the 13 Apr 08 at 17:29
|
upon further evaluation of your reference, maybe this will works as what i'm suggesting...???
please excuse my ignorance =)
|
|
smokebox46and2 wrote on the 13 Apr 08 at 17:55
|
WAIT! upon even further evaluation, i notice that Kai (the developer of this script) himself says "but it doesn't do a displacement. the modifier is ONLY subdividing the mesh so that the displacement modifier (or disp material) has enough vertices to do a detailed displacement."
case-in-point. the feature i'm requesting needs to be integrated with Blender's renderer to create displacemtnt at Render-Time based on a displacement map that is not dependent on the Displace Modifier. Kai's method is also dependent on the camera distance from the object being subdivided and the result is visible in the veiwport. This is more like real-time than render-time... too processor intensive, especially for 32-bit maps with a lot of detail.
Please look into Mental Ray's and VRay's render-time displacement for further details, as well as the link posted previously.
|
|
leojS wrote on the 15 Apr 08 at 19:41
| |
There was a micro-poly renderer (seperate from blender internal) in development by "eeshlo" called QDune, but I think development stopped (?) when peach decided they didn't want to use it or something...
|
|
hoehrer wrote on the 20 Apr 08 at 17:38
|
There was also some talk about the code beeing so complicated to integrate with the rest of the render-stuff in blender that not even the most skilled developers involved could've finished the integration (before peach) ... anybody knows more details? - this is all badly remembered hear-say.
That doesn't mean the code _can't_ be integrated, but as I see it right now there just isn't anybody working constantly to keep this cool project going :(
Werner
|
|
Handydan (Blenderstorm admin) wrote on the 20 Apr 08 at 21:43
| |
smokebox46and2, I don't see what there would be to gain in integration into the renderer when the modifier method of micropolys would seem to work just as well and be easier to implement.
|
|
smokebox46and2 wrote on the 20 Apr 08 at 22:36
| |
handydan, perhaps you're right. i'm just an organization freak... lol.
|
|
broken (Blender Developer) wrote on the 21 Apr 08 at 04:02
|
Handydan, that modifier is question is *not* the same as REYES-style micropolygon rendering.
It doesn't work just as well, it still subdivides the mesh before rendering and must keep the entire mesh in memory. The sort of micropolygon rendering as in qdune or renderman only subdivides geometry per tile, during the render process, and is much faster and more memory efficient.
|
|
smokebox46and2 wrote on the 21 Apr 08 at 05:20
| |
yay! a developer understands the technicality. thnx, broken. with all due respect, Handydan, broken is right--and this is the importance of the integration with the renderer, if i am myself understanding the technicalities.
|
|
Handydan (Blenderstorm admin) wrote on the 21 Apr 08 at 11:54
| |
broken, I understand that it is not the same. I'd like reyes rendering in blender just as much as the next person. I just don't think that it is likely to arrive soon, whereas there is definite progress with the modifier.
|
|
smokebox46and2 wrote on the 21 Apr 08 at 18:05
|
may we please remove the "in development" tag since we all understand that this request is separate from anything currently known to be in development for blender, and this is still a feature request forum (for which i am very grateful).
thank you
|
|
Cessen wrote on the 6 May 08 at 23:44
|
As Broken said, an adaptive subdivision modifier isn't the same as micropolygon displacement. To get "true" micropoly displacement, Blender's rendering architecture would have to be pretty fundamentally changed.
The main reason micropolygon displacements work is because micropolygons aren't slow in the context of the Reyes architecture. In Blender they would be slow and hog memory. (I'm not even sure they would really qualify as micropolygons anyway, as usually that term is exclusively used in the context of Reyes rendering, where each micropoly gets one color, and is shaded before sampling instead of the other way around.)
For Blender's internal renderer I think there may be better ways to achieve displacement mapping. For example, there are some pretty powerful image-based techniques that have come about thanks to realtime graphics research.
If you want micropoly's, best use an external renderer like Aqsis or Pixie. Or promote the integration of QDune.
|
Post your comment
|
