PDA

View Full Version : We don't need micro-poly displacement in LW



djwaterman
01-29-2015, 03:13 AM
Are we cool with not having true micro poly displacement in Lightwave? I mean, it seems no one ever mentions it, does that mean no one really wants it here? Do users know what it is and how seriously awesome it would be to have it in Lightwave?

I'm just mystified that I hardly hear anyone call for it. Perhaps you're all okay without it. Just find it strange that it's not seen as a priority.

lightscape
01-29-2015, 03:19 AM
Its not that nobody wants it. It probably requires a rewrite of the lightwave renderer. And of all the features in lightwave that doean't need much attention, its the renderer. Its good enough as it is. Octane renderer has it if you want it for lightwave.

lino.grandi
01-29-2015, 03:39 AM
Micro-poly Displacement has been mentioned several times, and we consider it something very important.

erikals
01-29-2015, 03:48 AM
we have DPont's, though have not tried it, so can't say how it operates, but check this link...
http://dpont.pagesperso-orange.fr/plugins/DP_MicroDisp.html

Andy Webb
01-29-2015, 03:51 AM
I often wish LW had micro poly displacement.

When you see it being used you realize how much detail can be add, bump and normal maps just do not add that sort of realism.

Andy Webb
01-29-2015, 03:53 AM
I did try DPont's a while ago and if I remember correctly it had some issues...

tonyrizo2003
01-29-2015, 04:39 AM
Well if you mean natively, then yes we do not have it. If you mean hving access to it besides DP Nodes, than there is Otoy https://www.lightwave3d.com/news/article/lightwave-3d-group-offers-the-ultimate-creativity-bundle-lightwave-116-and-octanerender-20/

MarcusM
01-29-2015, 05:12 AM
Interesting(idea) is shader for terrain what i use in Unity. It use normal and height, responds to light and keep mesh on low level. Not like displacement and tesselation.

djwaterman
01-29-2015, 05:15 AM
I mean natively, it would mean so much. Once you go to other renderers you have to change other things like materials and so on. I've tried the DPont microdisplace, but it's a different kind of solution. I've just had to go outside of Lightwave to do a specific thing using displacement, I look forward to the day I don't have to do that. I know Kray is planning to add it as a feature, but Kray 3 isn't even in beta stage yet so I'm hoping to see it in a future release of Lightwave.

MG artist
01-29-2015, 05:49 AM
I'm hoping to see it in a future release of Lightwave.
So do I, look at Pixar's renders, displacement on small things makes a huge difference, normal maps are just not enough sometimes.

prometheus
01-29-2015, 07:38 AM
we have DPont's, though have not tried it, so can't say how it operates, but check this link...
http://dpont.pagesperso-orange.fr/plugins/DP_MicroDisp.html

I also fired it up to try it, but at once it crashed on me, and I somehow just didnīt feel like messing with it.
I was probably not patient enough at that time.

Andy Webb
01-29-2015, 07:56 AM
I also fired it up to try it, but at once it crashed on me, and I somehow just didnīt feel like messing with it.
I was probably not patient enough at that time.

I think slowness to render and crashing were the problems I had.

Wade
01-29-2015, 08:02 AM
Its not that nobody wants it. It probably requires a rewrite of the lightwave renderer. And of all the features in lightwave that doean't need much attention, its the renderer. Its good enough as it is. Octane renderer has it if you want it for lightwave.

So if I we were to read between the lines - LW will see MPD in the future but you are not committing to it or a date and time. I do believe there are some very good things to come with LW in the near future MPD or not.
Thanks Lino for chiming in.

motivalex
01-29-2015, 08:24 AM
I think people have got bored keeping on requesting it for how many years. I'm sure it will arrive as a feature sometime, like instancing did eventually.

bobakabob
01-29-2015, 08:49 AM
Are we cool with not having true micro poly displacement in Lightwave? I mean, it seems no one ever mentions it, does that mean no one really wants it here? Do users know what it is and how seriously awesome it would be to have it in Lightwave?

I'm just mystified that I hardly hear anyone call for it. Perhaps you're all okay without it. Just find it strange that it's not seen as a priority.

Are there any good examples to show?

It would be cool if there was a development in this direction. There are times normal maps just end up looking like normal maps. Any disadvantages? Does MPD require lots of RAM?

jasonwestmas
01-29-2015, 09:23 AM
For closeup shots of a material micro-poly is a must, for everything else no, not really, obviously. Yes the shading of a tangent space normal map is not the best option. Plus there are UV seams to worry about with tangent space.

Sekhar
01-29-2015, 09:27 AM
Can't we just use APS (pixels per poly setting)?

jasonwestmas
01-29-2015, 09:48 AM
Can't we just use APS (pixels per poly setting)?

it does help to use that but it's not as efficient or as nice as micro-subdivision which subdivides smaller than a pixel. Not sure why it looks better but the sampling looks better for closeups. As resolution standards become higher and higher I think LW will need this to compete with the many other optional renderers out there.

raw-m
01-29-2015, 09:51 AM
Looks useful but also looks like it could be a render killer!

jasonwestmas
01-29-2015, 10:17 AM
Looks useful but also looks like it could be a render killer!

yeah that's why you don't apply it to everything. ;)

Ernest
01-29-2015, 03:11 PM
I'm just mystified that I hardly hear anyone call for it. Perhaps you're all okay without it. Just find it strange that it's not seen as a priority.

I think part of the reason is that we've all reached a sort of consensus that the most important thing for LW is getting a new geometry engine that allows transforming and deforming millions of polys fast. Everyone is kind of keeping all other feature requests quiet until that massive task gets completed.



Any disadvantages? Does MPD require lots of RAM?
Depends. The displacement will be as detailed as your map, so for super detailed closeups, you will need super large maps.

djwaterman
01-29-2015, 03:47 PM
Of course renders are slower when using it, but not as slow as using regular displacement and trying to get that level of detail. Let's face it, in the real world things are properly displaced, not faked with normal maps. I'd like the choice to decide when to economize with tricks and when to go all out realistic, and do it all in Lightwave. Sometimes tricks just don't cut it. Just knowing that LW3DG are aware of it is a good thing, They should always be able to boast about their renderer, it's a selling point.

MSherak
01-29-2015, 06:24 PM
Interesting(idea) is shader for terrain what i use in Unity. It use normal and height, responds to light and keep mesh on low level. Not like displacement and tesselation.

(Correct term is called Parallax Mapping or Relief Mapping)

Look here if you want it for LW> http://dpont.pagesperso-orange.fr/plugins/nodes/Additionnal_Nodes_2.html

-M

jwiede
01-30-2015, 06:40 PM
I think part of the reason is that we've all reached a sort of consensus that the most important thing for LW is getting a new geometry engine that allows transforming and deforming millions of polys fast. Everyone is kind of keeping all other feature requests quiet until that massive task gets completed.

I know I've not asked for micropoly render-time displacement lately personally, but because I view it as dependent on bucket rendering. I see no point asking for micropoly before LW3DG provides bucket rendering, but I do still ask for bucket rendering from time to time. I consider a revamped Layout geometry back-end largely as orthogonal to micropoly/bucket effort, indirect competitors for resources at best.

jasonwestmas
01-30-2015, 06:53 PM
I know I've not asked for micropoly render-time displacement lately personally, but because I view it as dependent on bucket rendering. I see no point asking for micropoly before LW3DG provides bucket rendering, but I do still ask for bucket rendering from time to time. I consider a revamped Layout geometry back-end largely as orthogonal to micropoly/bucket effort, indirect competitors for resources at best.

yeah buckets are kind of a rudimentary need that should technically proceed other rendering features I would think.

Amurrell
01-31-2015, 08:31 PM
Yeah, we need it. I was using it in my trials with Modo and grinning from ear to ear, then tried the same types of textures in LightWave later on and then remembered "Oh yeah, I have to subdivide the crap out of everything first". Been waiting a long time for micropoly displacement.

erikals
02-01-2015, 02:21 AM
not sure what the problems with the DP MicroDisplacement is,
http://dpont.pagesperso-orange.fr/plugins/DP_MicroDisp.html

but i'd think DP Relief Mapping could give --somewhat-- the same result...
http://dpont.pagesperso-orange.fr/plugins/nodes/nodes/ReliefMapping.html#ReliefMap


but yep, 'true' MicroDisplacement is needed in LW

sukardi
02-01-2015, 02:59 AM
From somewhat cryptic response from LW3DG, I am hopeful to see micro displacement feature within the 2015 cycle. Fingers crossed :)...

djwaterman
02-01-2015, 08:04 AM
The relief mapping has limitations of shadows, hard shadows only, plus it has no effect on the silhouette. I tried the DP MicroDisplacemment but it is a different approach, from memory you make the original object invisible and the displacement appears on a volumetic clone or something, it did my head in, I realized it wasn't what I thought it was but I'm sure it's suitable for some stuff.

robertoortiz
02-01-2015, 08:39 AM
Agreed 'true' MicroDisplacement is needed in LW

jwiede
02-01-2015, 11:54 PM
not sure what the problems with the DP MicroDisplacement is,
http://dpont.pagesperso-orange.fr/plugins/DP_MicroDisp.html

The problem is that, lacking buckets' segmentation, you wind up needing enough ram to hold the entire scene including all micro displaced geometry representations all in memory at once. In many to most cases, that requires many GB more RAM than most users have available, because micropoly displacement maps are basically sub-pixel-scale maps and enormous if not segmented by buckets.

dpont
02-02-2015, 12:29 AM
Speaking of DP MicroDisp,
I mentioned this, at the beginning of the web page,
"The micropolygons are generated on the fly without consuming memory"

Of course there's more RAM memory used,
because MicroDisp here is not included the LW Raytracer/Renderer
the basic object needs a minimum data in the preprocess for being
rendered as a surface volume, like a reference object in DP Instance
(with eventually same kind of limitations considering the quality of the mesh)
the trick is to find a compromise between for subdividing/tesselating
the basic object.

Smoothing the micropolygons is also slower.

Beside the integration in the main renderer,
I suppose also that the micropolygon generation algorithm
could be accelerated with special coding available with recent cpu processor.

Denis.

magiclight
02-02-2015, 07:34 AM
The buckets normally just split the frame buffer in smaller areas because micro polygon rendering need anti aliasing so a large frame buffer is needed (a 1024*768 might need 4096*3072 frame buffer or more), and buckets solve that problem, it does not have much to do with micro polygons, this is done one object at the time with or without buckets and then the micro polygons are thrown away (with GI it can be a way around memory hogging, but there are better ways to solve it)

As long as you stay away from GI there is no need to keep any micro polygons, Rayes renderers just split and dice objects and just render a small patch of micro polygons at the time, so no matter how complex the scene is it will not use more memory (texture cache is used for textures, and some more memory usage come when objects cross buckets but no need to keep lots of micro polygons in memory, just the objects).

Of course if we talk GI it's different, the rays can fire anyway so the geometry is needed at all times in theory, but there are ways around that also with ray coherence caching, rays are collected in coherent groups and fired later when enough rays are collected in a group so that all geometry does not need to be tesselated at the same time, but yes GI makes it much more complicated.

Polygon smoothing is really fast in those kind of renderers because it's all in a grid and floating point hardware (SIMD) does it in parallel one quad at the time.

jasonwestmas
02-02-2015, 08:02 AM
That's interesting magiclight. I for one would be using GI if I needed to use micropoly subDiv.

chikega
02-03-2015, 10:13 AM
We also need Vector displacement as well :)

erikals
02-03-2015, 11:08 AM
yes, and a way to generate them also.

i seem to recall a DP node can generate them,
https://www.youtube.com/watch?v=VzwGFHnvz9g
can't recall, long time ago...

there is a DP node to use them at least... http://erikalstad.com/backup/misc.php_files/smile.gif


https://www.youtube.com/watch?v=oI6SOjUYDcs

jump on NT...

Cageman
02-03-2015, 04:10 PM
I know I've not asked for micropoly render-time displacement lately personally, but because I view it as dependent on bucket rendering.

Hmm... are you sure buckets are needed in order for it to work without huge memoryconsumption? I mean... look at Octane... it doesn't render with buckets (at least not visually so). Maybe it does something not visible for the user though? I have seen it using a sort of bucket system when using it with the IPR and using networked machines, but that could also be a clever "camera region" type of solution?

magiclight
02-04-2015, 02:21 AM
As I said above, buckets don't do anything for micropolygon displacement, it's only there to handle big framebuffers (resolution*samplesize, micropolygon rendering cause lots of aliasing artifacts), the only time you have memory related problems with micropolygon displacement is in GI because you need access to all geometry all the time, without GI you can just render one patch of micropolygons and then throw it away, there is really no limit to how much geometry you can render.

VPR may be another problem child on the other hand.