So, can EI do displacements?

[Reuben5150]

I don’t think having to use 2 displacement map would be that “painfull”, yeah i’ve done it, the real problem is that there is visible lines around the transition between +/- maps.

did someone mention this ?

Reuben

[AVTPro]

So yes, two problems with the mapping, as mention. One, the character of the form changes. So it can look really bloated or scrawny. (manuel)

two, any overlap of common area or cross references of where the maps are separated can (+/-) will cause anomallies.

But yes, I think all the jump through hoops to get one map to work right but disecting it in photoshop is a pain as oppose to using one simple map, especially if you make many changes in ZBrush.

Igors again thanks. And I am trying to convey the info. First, I am not concerned about bump mapping tho I do think that Displacement should not be dependent of bump setting but displacement should be addressable by itself without bump.

I believe we are not on the same page, I hope this illustration may help.

[left]the size of the hill, or pit stays the same. but just using positive or negative will make two different forms like depending on pos/neg map setting. My Moon Man came like a fat head puffy face and lost lots of detail in the form because I only use pos. He look sick and starving when I use just negative maps. To split the map was very tedious everytime I did a test and makes abstract pattern like solarize or posterize where values get confused.

Zbrush use one map where nuetral or no amplitude is at 128 grayscale value out of 256 (including zero). No confusing in values from light to dark. 50% grayscale is sea level or the non affected geometry surface (or 128.)

Each hill is the same size.

[/left]

[AVTPro]

I don’t think having to use 2 displacement map would be that “painfull”, yeah i’ve done it, the real problem is that there is visible lines around the transition between +/- maps.

did someone mention this ?

Reuben

Yes, Rueben…I did, based on your work. I personally haven’t got a map to look good enough to see it, but I understand why it’s happening. it’s a another reason why using Photoshop to separate a single map will cause problems. Any descrepancies within the curve overlap will cause an solarized rim. There use to be programs or filters that create the effect by the same difference overlap.

Also, if you have two map, the two value can become cross referenced on the same surface. 127+ and 127- would cause 128 or noise distortions. There’s no way of knowing what you’ll get in the render with the current paradigm.

[Igors]

Hi, Manuel

I understand that the amount of displacement remains the same, but the volume, and the character of some shapes changes. Here is another illustration of what I mean:
Imagine this being a “W” from a 3D logo, and you wanted to make the lettering look like rock.

If I were to apply the same displacement to a flat surface to create a terrain, it wouldn’t matter, but with an enclosed shape, it does.

Absolute yes, but don’t overestimate advantages of this way. The attachments are what Reuben and we experimented with.

[Igors]

Hi, Alonzo

I believe we are not on the same page, I hope this illustration may help.

There are 4 pictures (from left to right)

Picture 1 - default (positive) EI displacement

Picture 2 - it corresponds to negative displacement direction WITH inverted source map. “Just negative” looks like mirror (X-axis), i.e. hills and pits are swapped

Picture 3 - it’s possible to obtain but with a lot of ventures: need to cut off a half of first map, and “another one half” of second inverted map etc. etc.

Picture 4 - no comments, we don’t know what ZB does

[Igors]

Hi, Reuben

I don’t think having to use 2 displacement map would be that “painfull”, yeah i’ve done it, the real problem is that there is visible lines around the transition between +/- maps.

did someone mention this ?

We think the real prob is UV seams rendering

[manuel]

Hi, Manuel
Absolute yes, but don’t overestimate advantages of this way. The attachments are what Reuben and we experimented with.

It depends on the amount of displacement how much it matters. Ever seen the stuff that Taron does? http://pixologic.com/Neckling_A06.mov.In that sort of case, you will want to be as faithfull to the original intention of the displacement map as possible. In fact, let me ask the question the other way around: The person who painted that displacement map in ZBrush has probably spend close to a day or more on it. Don’t you think that artist will care about how faithful the renderer interprets his/her work? I’ve worked with enough art-directors and designers to know that they do.

[Igors]

Hi, Alonzo

First, I am not concerned about bump mapping tho I do think that Displacement should not be dependent of bump setting but displacement should be addressable by itself without bump.

Hmm… sorry, Alonzo, but it looks like you confuse “a feature with a bug” IMO “bump and displacement together” (in one map) is a powerful EI feature that other cool apps have not. Traditionally “displsacement map” is applied not to each rendered point, but to each vertex to change its position AND to modify the normal of this vertex. It’s like we would use a high resolution model with vertices colors instead of bitmap texture. Of course, you can use displacement map and bump map, but it produces problems cause surface normals are perturbed twice.

EI method has no such problems cause displacement and bump work together, syncronously.

[Igors]

Hi, Manuel

It depends on the amount of displacement how much it matters. Ever seen the stuff that Taron does? http://pixologic.com/Neckling_A06.mov.In that sort of case, you will want to be as faithfull to the original intention of the displacement map as possible. In fact, let me ask the question the other way around: The person who painted that displacement map in ZBrush has probably spend close to a day or more on it. Don’t you think that artist will care about how faithful the renderer interprets his/her work? I’ve worked with enough art-directors and designers to know that they do.

We hope we understand well that a good realistic displacement map is a careful work takes a lot of artist’s time. But what do you ask us about - that’s not clear for us. Please be more concrete.

[AVTPro]

Hi, Alonzo

Hmm… sorry, Alonzo, but it looks like you confuse “a feature with a bug” IMO “bump and displacement together” (in one map) is a powerful EI feature that other cool apps have not. Traditionally “displsacement map” is applied not to each rendered point, but to each vertex to change its position AND to modify the normal of this vertex. It’s like we would use a high resolution model with vertices colors instead of bitmap texture. Of course, you can use displacement map and bump map, but it produces problems cause surface normals are perturbed twice.

EI method has no such problems cause displacement and bump work together, syncronously.

I never called it a bug
Just a preference, not to address two settings, for one feature.
Displacement in EI won’t work without adjust bumps. Just like painted Displacement maps, two maps must be addressed for one effect. Highs and lows is asynchronous…from my chart

[AVTPro]

Hi, Reuben
We think the real prob is UV seams rendering

    I can't agree with you here. (but I'm not a bad guy for that :)
    
    There are no UV seams with designed UVs and GUV. That's why I studied it to get around the rectangular slits from Auto UV mapping. I have 3 character with no seams.  AUV seams is very rectrangular. I dont' use Auto UV mapping because I would like to futher edit maps in PS. ( However Zapplink has made that a breeze.) The patterns we are talking about are from the overlap of map separations.  Having to separate one grayscale image by clipping and translating is inherently flawed. It's a messy, non artistic, ineffecient procress resulting in an organic soloarized pattern.  It is also an extra step that other Zbrushers don't have to do. In Maya there's a small script that I will find that show how to offset the image values in the renderer.
    
    I understand that Zbrush is a very new revelutionary approach that not all renderers have caught up with. It's understandable, but users like Rueben, Lolo, Manual and myself are artist aching to use this advanced technology with their old favorite render engine.  The artist are very familiar with ZBrush and have done many tests and much research. They are the ones who have come up with many inventive workarounds. My only contribution was "No Seams" tutorial.  [http://homepage.mac.com/avtpro5/.cv/avtpro5/Sites/.Public/AVT-ZB2EI-no%20seams.mov-binhex.hqx](http://homepage.mac.com/avtpro5/.cv/avtpro5/Sites/.Public/AVT-ZB2EI-no%20seams.mov-binhex.hqx)
 
 
 Dont get me wrong, without Igors and Encage, success with Zbrush would be much furhter away. I speak very highly of it in the "no seams" tutorial.
    
    But who knows when EI will do subpixel displacement or 16bit? I ask for much smaller request than this, micropoly or 16 bit. 

Color maps painted in ZB with GUV works very well in EIAS. I would to see displacement maps work the same. "One map displacements with full range option where 128 value is nuetral." It's one option or fix that will keep EI in the leagure of  world's best renders. 

Zbrush has ways to fix seams, and make 8bit grayscale displacements.

[manuel]

Hi, Manuel

We hope we understand well that a good realistic displacement map is a careful work takes a lot of artist’s time. But what do you ask us about - that’s not clear for us. Please be more concrete.

Well, you joined the conversation saying that a centred displacement (=50% grey is neutral)is not all that it’s cooked up to be. I’m just trying to figure out why you think so. Surely if a displacement map was created with a centred displacement in mind, that’s how EIAS should apply it. The example with the three heads you posted may look okay to some, but to many art-directors, it wouldn’t be acceptable.
I know that you guys aren’t EITG, so this isn’t a feature-request. I’m just trying to understand where you’re coming from. Maybe a centred displacement-button in EIAS v7 would add more problems than solve them? If so, what would they be?

[Igors]

Hi, Manuel

Well, you joined the conversation saying that a centred displacement (=50% grey is neutral)is not all that it’s cooked up to be. I’m just trying to figure out why you think so. Surely if a displacement map was created with a centred displacement in mind, that’s how EIAS should apply it. The example with the three heads you posted may look okay to some, but to many art-directors, it wouldn’t be acceptable.

Yes, that’s what we wanted to explain. “It’s better one time to see instead of 100 times to hear”

I know that you guys aren’t EITG, so this isn’t a feature-request. I’m just trying to understand where you’re coming from. Maybe a centred displacement-button in EIAS v7 would add more problems than solve them?

Well, IMO there is nothing bad in this option, just it gives much more modest results than it’s expected in first view

If so, what would they be?

As you noticed (absolute correct) we are not EITG. If you ask our personal opinion, that is: the task should be a “compatibility between EI bump/displ and ZB” and let this formula says what buttons/options should be

BTW: according to rules here you should be 65-70 years old to call us “guys”

[Igors]

I understand that Zbrush is a very new revelutionary approach that not all renderers have caught up with.

Looks like Camera needs to learn from ZB how to render, hah? We’ve another opinion. We don’t try to judge how revelutionary ZB approach is, but we know well: their exported maps are not suitable for any universal render engine (count Camera). Cause anywhere texture is anti-aliased, blurred and mixed and all these operations are performed in continuous image space. In other words, ZB has added a headache for renderers, and ZB is absolute not in hurry to fix it.

[bronco]

Looks like Camera needs to learn from ZB how to render, hah? We’ve another opinion. We don’t try to judge how revelutionary ZB approach is, but we know well: their exported maps are not suitable for any universal render engine (count Camera). Cause anywhere texture is anti-aliased, blurred and mixed and all these operations are performed in continuous image space. In other words, ZB has added a headache for renderers, and ZB is absolute not in hurry to fix it.

excuse me if i step in here.
i don’t think that camera needs to learn from zbrush. camera does a good job, the problem is that if you want to push and pull a mesh at the same time without changing other parts of the same mesh you need to use two maps in eias. this is a potential problem at the overlapping areas.
i haven’t used zbrush, but as i understand it uses 50% grey at places which will not be affected by the displacement, this is also true for 3d max. i guess this is for maya the same (correct me if i am wrong here).

so, if eias had the abillity to change this behavior (a preference switch, maybe?) it would not only open a painless pipeline for zbrush, but also simplyfy the process of displacment mapping in eias in general.
again this is not so much about the normals of displaced areas, but instead of the whole geometry which gets distorted.

if i said something wrong or missleading, please correct me.

uwe

[AVTPro]

Looks like Camera needs to learn from ZB how to render, hah? We’ve another opinion. We don’t try to judge how revelutionary ZB approach is, but we know well: their exported maps are not suitable for any universal render engine (count Camera). Cause anywhere texture is anti-aliased, blurred and mixed and all these operations are performed in continuous image space. In other words, ZB has added a headache for renderers, and ZB is absolute not in hurry to fix it.

 ILM has officially approved ZB as a tool that will be adopted into their film production pipeline. Luma's "Underworld" is noted for ZB. 
 

 Softimage, Maya and Renderman all work well with subpixel, 16 bit, ZB maps for film. EIAS has always been a film quality renderer alternative on par with Renderman in image and film grain.
 
 Yes, it's always a headache breaking new ground.
 
 
 My point is:
 
 1. a 128 value nuetral displacement map is the first shortest. best step in functionality bringing EI back into the  racks of renderers that use ZB for film. I believe it would be the most useful improvement of all 3 to artist wanting more image attributes, and less of a task to than reprogramming a 16 bit renderer with micropolys.
 
 2. One single map is quicker, less encumbered workflow for using 8 bit grayscale disp.maps than cutting up images in photoshop. 
 
 3. Overlap decrepancies and posterizing surface normals will be irradicated with one single map. 
 
 4. More control  over displaced surfaces being distorted bloated or being shrunken by artist foregoing the complexities of the forementioned  workflow to settling for either positive or negative map. 
 
 5. I won't have to get a big headache learning Renderman or some other Maya Renderer. :)

[iKKe]

This is an interesting video about the same subject & file:

http://content.luxology.com/modo/201/video/ZB-Basic-01.mov

Cheers

Hans

[AVTPro]

Hi, Manuel
Absolute yes, but don’t overestimate advantages of this way. The attachments are what Reuben and we experimented with.

I would have to agree with Manuel. Those images in certain circles wouldn’t cut it. I blame the render specs, definitely not Rueben

http://206.145.80.239/zbc/showthread.php?t=003548

I see not advantage in not being able to control how the displacement inflate or shribbles the contours of the model design.

I was very disappoint with this render of my moon. A simple grayscale moon texture either bloat the face or shribble it. It changes the personality of the character.

Maybe you can’t see it but it urks the heck out of me and I never finished this project. I should have been able to put that moon texture and use it’s natural pattern to convex and concave the surface without any special photoshop treatment.

http://homepage.mac.com/avtpro5/PhotoAlbum38.html

[FelixCat]

Hi, Alonzo
Very simple and clever way to handle disp. maps in MODO… i wish we have something like this in EiAS. I have been reading very carefully all this treath, because i will need soon to use ZB models very detailled in EiAS, but i´m not so sure if it will fit the task. Allways i can export the model, from ZB, with all the detaill and all the polygons. Arround 1.000.000 polys!
Not spetially the best solution at all…

FelixCat

[manuel]

BTW: according to rules here you should be 65-70 years old to call us “guys”

I just added the ages of both Igors up Let me know if I did the maths right.

Maybe you can’t see it but it urks the heck out of me and I never finished this project. I should have been able to put that moon texture and use it’s natural pattern to convex and concave the surface without any special photoshop treatment.

Alonzo, I hear you loud and clearly. That is EXACTLY the reason I started this thread. I have this personal project I would love to do in EIAS. For months it sat on my hard-drive, and every time I went back, it was all the hassle with displacements that put me off. The thing that saved me was my brand new G5 which allowed me to do render-tests within a reasonable time-frame.