displacement test (final)
displacement test (final)
This is just a test I did while cooking a new angle on my plastic robots. I wanted to know whether Blender displacements could be useable in an interior or if they would just send everything crashing due to the size of the meshes.
It sorts of works, though the rest of the scene is by no means heavy. The stone wall accounts for about 90 per cent of the polys. To lighten the scene for indigo, I projected the tileable texture once onto a plane, which I divided quite a few times, and instead of tiling it, I copied several instances of this plane, each corresponding to a tile, and pasted them alongside each other to form the wall.
(Armchair by evermotion)
It sorts of works, though the rest of the scene is by no means heavy. The stone wall accounts for about 90 per cent of the polys. To lighten the scene for indigo, I projected the tileable texture once onto a plane, which I divided quite a few times, and instead of tiling it, I copied several instances of this plane, each corresponding to a tile, and pasted them alongside each other to form the wall.
(Armchair by evermotion)
- Attachments
-
- im1197329548.jpg (272.91 KiB) Viewed 18971 times
Last edited by BbB on Sat Dec 15, 2007 9:50 pm, edited 2 times in total.
Thanks Ono, I'm going to try with a different map tonight. The values are quite tricky. Even with so much subdivision (the wall alone is about 300,000 polys), smoothing errors start becoming visible as you raise the value. IN fact, the value is probably a bit high now. I'm trying to get to the bottom of what the best displacement/bump compromise could be. Obviously, with so many polys, this only works with very simple scenes. It's not so much a problem with Indigo thanks to instancing, but the limitation is Blender (no Win 64 bit version and massive viewport slowdown) and the exporter.
BbB:
1) Great looking test - that's the extent of my displacement in blender testing, so I'm interested in what you come up with.
2) Either compile Blender with the /LAA switch or download a build from graphicall.org with it compiled in. I've successfully crashed blender at 3.6 gb (trying to import one of the stanford .ply models) on my win x64 laptop; instead of the usual 1.6gb limit.
Not that viewport slowdown is the memory problem: we need/someone needs to hack in a raytraced viewport into Blender, because sending 7 million polys to a videocard (depending on the card) is uselessly slow. Conversely, in the "play" version of Radium2, the viewport stays nice and useable, even with the aforementioned .ply model in it, since it's raytraced.
1) Great looking test - that's the extent of my displacement in blender testing, so I'm interested in what you come up with.
2) Either compile Blender with the /LAA switch or download a build from graphicall.org with it compiled in. I've successfully crashed blender at 3.6 gb (trying to import one of the stanford .ply models) on my win x64 laptop; instead of the usual 1.6gb limit.
Not that viewport slowdown is the memory problem: we need/someone needs to hack in a raytraced viewport into Blender, because sending 7 million polys to a videocard (depending on the card) is uselessly slow. Conversely, in the "play" version of Radium2, the viewport stays nice and useable, even with the aforementioned .ply model in it, since it's raytraced.
Funny, I was myself playing with displacement tonight. I figured out that by applying the same displacement map various times to a plane I could get a messy soil with random rocks for cheap (consecutive disp have the effect of inflating the details, while after first disp pass they are just pulled out).
obsolete asset
Here, a better illustration. Quickly thrown, I hope you don't mind BbB...
The texture, a simple fractal with threshold.
The texture, a simple fractal with threshold.
obsolete asset
Who is online
Users browsing this forum: No registered users and 35 guests
