Mudbox displacement maps in T2

Started by TheBadger, May 17, 2013, 10:25:30 AM

Previous topic - Next topic

TheBadger

Ok, so it turns out I did have a little experience with vector maps. In mudbox they are a way to get and repeat intricate details with overhangs, quickly.

With respect to overhangs, will this work (essentially) the same way in T2? So if in paq's example there were (for example) scales where the edge was slightly lifted, this would come through correctly, on a terrain or otherwise? Im guessing yes.
It has been eaten.

Matt

Quote from: gregsandor on May 17, 2013, 10:46:20 PM
When can we expect displacement on models with raytracing?

We have a roadmap for achieving that. My best estimate is about 1-2 years from now if we stick to the plan. However, much sooner than that we will provide options for selecting which objects are ray traced and which are rendered with the micropolygon rasteriser with displacement.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

j meyer

Did a first try with ZBrushs VectorDisplacementDiagnostic files,but all I got were
lots of Bucket errors and vanishing geometry.(The disp map is exr by default btw)
Will try again and report back here.

Tangled-Universe

Paq, thanks for sharing that result. Good to know such things are possible :)

TheBadger

Quote... However, much sooner than that we will provide options for selecting which objects are ray traced and which are rendered with the micropolygon rasteriser with displacement.

Matt

Matt, Do you know yet if that will be per object or also per population? Will we be able to do it to an object and a population of a different object at the same time?
It has been eaten.

TheBadger

#20
[attach=1]

[attach=2]

Its crappy. I spent nearly 8-10 hours modeling a replica of the complex grounds of "the temple of Zeus", in Athens. And then got an unknown error in Maya. All was lost. I had two versions. 1 was rather literal. And the other was a creative departure. I added some things I thought would be nice, including a ornate pool. Was going to make a mask of the pool shape to displace the terrain with, so it would be easier to fill with water...

Restarted it this evening, but only concentrated on the columns. Ill get back to the complex this week. But will share the columns as soon as one is finished.

The columns here are a departure from the source inspiration, which are corinthian. I went with a more roman meld of Ionic and Doric.
Not finished modeling yet, and then have to detail/sculpt. But at the very least you'll be able to make something like this:
http://upload.wikimedia.org/wikipedia/commons/1/1f/National_Capitol_Columns_-_Washington,_D.C..jpg
If not something more complex in arrangement.

I'll include the low polly with high polly masks, as well as the high polly sculpt... Incase we cant get the maps to work for some reason... And for close ups.
It has been eaten.

j meyer

Yes! ;D It works great,all I had to do was to activate the 'Data is linear' option.
Thanks to paq for pointing that out.
Nothing else necessary.
[attachimg=1]
The number below the perfect sphere is the value to be entered in ZBs export
settings and then everything will be automatically flipped and swapped on
export.
Thanks Matt and anyone else involved,great feature!

TheBadger

^^
Pardon my brain hole, J. But what is being demonstrated in the image you posted? I don't understand what the object in the render is.
It has been eaten.

j meyer

It's a test object you use to import into your rendering app of choice to see which
settings (of 48 possible) you have to choose in ZB for export.Maya needs other
settings than max or modo or whatever.So instead of going through all 48 posssible
variations you just export the given test files (1obj/mtl,1bmp,1exr) import them into
your rendering app load the exr into a material(or in this case the image map shader
connected to the VDisp shader) and render.One of the 48 little blobs (no disp)
should render to a perfect sphere then.In this example it should be the one with the
number three below it and like said before:
"The number below the perfect sphere is the value to be entered in ZBs export
settings and then everything will be automatically flipped and swapped on
export."
Hope it's more understandable now

Tangled-Universe

Thanks for the info meyer :)

I wonder though, what about #48 then? That looks "spherish" to me too? #20 has a glitch in the shadow, but looks quite correct too.
Not really relevant, just wondering.

j meyer

Take another look ;)
Seriously, #48 is not a sphere,you can see that by looking at the shadow line
(light is default btw).#20 ditto,I'd say.
Maybe I'm wrong,we'll see when I perform the next test later today.

TheBadger

Just wanted to say Im still working on the models. Since Im going to share, I want them to be as nice as possible. And I guess, despite how important something feels to me when I first think of it, there is not really a reason to rush.  ;D

Besides, my wife will give birth this week or next, so things are a bit crazy around here  :o  :)
It has been eaten.

j meyer

#27
Take your time and good luck.


#3 was the right one.
Now for the bad news,there are some issues I didn't notice and/or think of yesterday.
Look at the no disp and the vdisp again and you'll see the shadows are the same.
I think Richard (cyphyr) had that happening before with displaced planes iirc.
It becomes more obvious when rendered bigger or with protrusions and so on.
That's of course not really desirable for object rendering.But there's nothing you
can do about it as a user,except cheating or tricking the eyes or postwork maybe.
Another problem is the fact that low poly objects can have pretty bad shadows also,
talking about the shadows that are on the object itself here,when the poly resolution
is too low.So one has to find the right balance.In other rendering apps you would simply
add some subdivision levels,preferably on rendertime,to solve that,for use in TG you have
to try with different polycounts to see what works best for your purposes.
ZB users will have to deal with ZB not exporting normals (less mb,smaller obj files) and
TG2 not generating normals on imported objects (other apps do that btw).There are
workarounds so it shouldn't be much of a problem.
Didn't get to test everything thoroughly yesterday,so some more tests are required.
Will keep you posted.

Does TGs renderer use smooth uvs internally?


TheBadger

J, higher polly counts in objects will nearly always improve appearance anyway. In Mudbox to maya, I have found that if the low polly is increased at least one smoothing level above the base, and then Mudbox maps are rendered to that, the quality is increased compared to the absolute lowest level model (mental ray)... If that makes sense.

can you post a render of what your seeing, because people will have different tolerances to what is acceptable. Maybe the issues you are seeing will not seam so bad to us?

It has been eaten.

j meyer

It makes sense and I thought I was refering to that already:"In other rendering apps you would simply add some subdivision levels,preferably on rendertime,to solve that...."

I'm preparing some pics to illustrate,it just needs some time.