PDA

View Full Version : So, can EI do displacements?


manuel
03-26-2006, 10:24 PM
I've been having this problem with displacements in EIAS for quite a while now. So much so that I was seriously considering switching to something else this weekend.
Here you can see an example of the artefacts I keep getting. This happens with noise-shaders (NX, NoiseFactory) as well as bitmaps. The latter one to a lesser degree. And if you think those artefacts don't look too hot in a still, wait until you see them dancing around in animation.
All I did was apply some displacement with NX and then layer a white image on top in the diffuse channel, and this is the result:
http://www.geocities.com/manuroig/displacement2.jpg
The one thing I haven't tried yet is normal-mapping, since I haven't got anything that can create normal maps. So here are a few questions:
-Can normal maps be used for displacement, or are they only for Bump-maps?
-If "yes", would they get rid of the above problems?

P.S. some of you may have seen me posting about this on the EITG forum. Apologies for the repetitive posting, but so far I haven't had any answers.

Vizfizz
03-27-2006, 12:07 AM
What values are you entering in the displacement and bump map fields?

manuel
03-27-2006, 07:41 AM
At the moment I'm playing around with a character that's about 140 units high in Animator, in NX I'm giving it a displacement value of 0.1 and it already occurs. Bump map values don't seem to make a difference. Changing the resolution of the mesh doesn't make a difference either. The real problem here is the white image map, it brings out all the mistakes, without it, those artefacts would disappear in the NX texture.

I would like to be able to use quite high values to make the model look a bit more beaten up, but I'm not going anywhere near the displacements you see some people using when applying displacement maps from Zbrush. I remember seeing a test in C4D where they turned a cube into a sphere, just by using a displacement map.
Again, I'm not anywhere near those values. The only differences between those examples and me that I can think of are: A. I use EIAS B. I guess they were using normal maps.

So would normal-maps give me a cleaner displacement?

P.S. I could try and upload an example project if that would help.

halfworld
03-27-2006, 12:22 PM
Normal maps are for bump use only.
Could you upload a project file?

I thought 6.01 fixed this bug...
If it is the bug I'm thinking of, it is caused by badly welded vertices, so polygons become detached from one another when displaced...

I've done far more daring things with displacement before so I'm quite confused by this...
Ian

Igors
03-27-2006, 02:00 PM
Hi, Manuel
P.S. I could try and upload an example project if that would help.
We see no ability to help you without prj. You can use our e-mail for larger files (up to 1 Mb). No NX please (here you need to ask David and Luis).

manuel
03-27-2006, 10:56 PM
Thanks for the help guys, I solved the riddle. As it so often happens, I managed to solve the riddle while creating the project files I was going to upload here, I guess it's the perfect devise to concentrate the mind. The problem was lack of resolution in the mesh and the wrong choice of noise. Some noises seem to be more suitable for displacement than others.

AVTPro
04-23-2006, 05:01 AM
BTW, there's some free utilities or PSD type filters to create normal maps. Unfortunately I don't know where they are but they do exist. I use Zbrush.

I would love to see the whole Zbrush/Displacement/EIAS giant pinned down. It would be great if we had a thread of contributors that really nailed the process.
I need to wrap my head around DE options (Displacement Exporter for ZB). The good thing is, when the right options are working with EIAS 8bit diplacement renderer, a simple script line from DE can be posted and shared.

I still have this question mark in my head about EIAS 0-255 displacement range. I forgot how EI's displacement works (0=128 grey?) My thought is I won't have to use Lolo's PS (+/-) curves with the right DE settings.
I would be very happy with EIAS...beside the tearing wmp problem.

Ok...where did I put that slingshot?

manuel
04-23-2006, 12:44 PM
I still have this question mark in my head about EIAS 0-255 displacement range. I forgot how EI's displacement works (0=128 grey?) My thought is I won't have to use Lolo's PS (+/-) curves with the right DE settings.
I would be very happy with EIAS...beside the tearing wmp problem.

Ok...where did I put that slingshot?
A displacement map either works positive or negative in EIAS. So either the model inflates or it deflates. You would have to load two displacement maps, one with a positive value and vice versa, to get it to work "properly". I was checking out the C4D demo the other day and noticed that they have an option to keep 50% grey as neutral, so it's not impossible to program.
Add to that the fact that there is no micro-polygon displacement, a less than helpful shaderball and you get all the ingredients for a non-technically minded person like myself starting a "Can EIAS do displacements" type of thread.

AVTPro
04-23-2006, 04:53 PM
A displacement map either works positive or negative in EIAS. So either the model inflates or it deflates. You would have to load two displacement maps, one with a positive value and vice versa, to get it to work "properly". I was checking out the C4D demo the other day and noticed that they have an option to keep 50% grey as neutral, so it's not impossible to program.
Add to that the fact that there is no micro-polygon displacement, a less than helpful shaderball and you get all the ingredients for a non-technically minded person like myself starting a "Can EIAS do displacements" type of thread.

I don't care how technically inept one may be, if you say "Sub-pixel, micro-poly displacement mapping" in a crowd, they will be talking about how smart you are way after the party is over. :)

I believe there's option in DE to dumbdown the 16 bit to 8 bit. Also I think there is an option to turn the nuetral to black in DE. Or it's generate both +/- maps from DE.

Thanks, that jeered my memory. Yes, EI should have an option that converts map to 50% as nuetral. Then go up and down with one map. Maybe it can be done with XP (?) I really dislike the two maps>PS curves>plus/minus workflow. It's meticulous and time consuming, especially if you fighting seams at the same time.

I found options to fix seams in ZB, but I haven't use AUV (autoUV) since I learn my own UV editing I used GUV.

Ok Let's will give it a whirl and see what we get this time!

Igors
04-23-2006, 05:37 PM
Hi, Alonzo
Thanks, that jeered my memory. Yes, EI should have an option that converts map to 50% as nuetral. Then go up and down with one map. Maybe it can be done with XP (?) I really dislike the two maps>PS curves>plus/minus workflow. It's meticulous and time consuming, especially if you fighting seams at the same time.
1. Well, why 50%? Maybe 25% or 70% would be same or more usable for some map(s)?:twisted:

2. It cannot be done with XP, but for EI procedurals there are no any obstacle to use any midpoint they want.

3. Any changing of midpoint affects only object's "geometrical size" (like it's bigger with mid 0 and smaller with mid 0.5), but all surface normals remain absolute same. So, we've doubts that another midpoint would make you happy ;-)

manuel
04-23-2006, 07:53 PM
Hi, Alonzo

1. Well, why 50%? Maybe 25% or 70% would be same or more usable for some map(s)?:twisted:

2. It cannot be done with XP, but for EI procedurals there are no any obstacle to use any midpoint they want.

3. Any changing of midpoint affects only object's "geometrical size" (like it's bigger with mid 0 and smaller with mid 0.5), but all surface normals remain absolute same. So, we've doubts that another midpoint would make you happy ;-)
Hang on, we're all talking about the same thing aren't we? Here is how I understand it:
http://www.geocities.com/manuroig/displ-cgtalk.gif
The last circle represents what we currently can't do in EIAS. Or so I thought. Now you guys are saying that for instance NX could do this if Konkeptoine chose to put that in. Unless NX can already do this but I've never managed to figure out how.

Igors
04-23-2006, 08:35 PM
Hi, Manuel
Hang on, we're all talking about the same thing aren't we? Here is how I understand it:
The last circle represents what we currently can't do in EIAS. Or so I thought.
Yes, we're all talking about the same thing, your illustration is absolute correct. However, please count that all 3 shapes have different geometry but same surface normals. So, maybe, "magic 50%" is not what you need.

Now you guys are saying that for instance NX could do this if Konkeptoine chose to put that in. Unless NX can already do this but I've never managed to figure out how.We wrote: for EI procedurals there are no any obstacle to use any midpoint they wantYes, we confirm that EI shader has ability (no obstacle, right?) to use absolute any midpoint (same as any displacement direction). But we didn't say that NX (or other shader) already does this (cause, at least, we never seen NX :))

AVTPro
04-23-2006, 09:06 PM
50% represents the nuetral grey or 128 that Zbrush considers sea level or ground zero...no change in displace geometry. So, anything lighter (128-255) will be elevations in the surface geometry or darker (128-0) would be craters or imprints in geometry.

My desire to have EIAS follow this 128 nuetral mid surface setting is so that one map, from ZB would create both hills and valleys in displacement renders. I think we would then only need to input the alpha depth factor to get a very predictable results with a simple workflow.

So here's the current paradigm for ZB to EIAS. Export the Displacement map, then load it into PSD to be disected into 2 maps because EI reads zero to be black to be nuetral gray and 128 as an elevation from 0, not nuetral but upper hillside properties.

Even now, just thinking of it is confusing. I understand. In EIAS, -255 must be 100% indentation as oppose to zero (0).

So as in Manual graph EI's displacement range is -255 to 255 then Zero is nuetral.

So in PSD, it's confusing with the displacement image data values are being clipped (cut off) or translated, (transmuting or pushing the tones to a darker or lighter value. )

Ok...at least now I think I understand the problem.

Igors
04-23-2006, 09:16 PM
50% represents the nuetral grey or 128 that Zbrush considers sea level or ground zero...no change in displace geometry. So, anything lighter (128-255) with be elevations in the surface geometry or darker (128-0) would craters or imprints in geometry. Alonzo, you'll see SAME elevations and craters with 50% as they are with 0%, sure :)

AVTPro
04-23-2006, 09:26 PM
Grr...I understand the heart of the problem now. Zbrush divides one grayscale range (0-255) to handle both indentations and elevations simultaneously. In EIAS current displacement model, you can never interactively paint the displacement image (whether ZB or PS) if you need to set a minus or a positive value on one image which is/was interactively painted from light to dark as in ZBrush.

Funny, you can't do it in Maya either but you can set an expression to push values around (or negate an offset by .5 into indentations) which solves the problem. There is a script for Maya, but if XP can't do anything with it there's no need for me to post it.

:-?

manuel
04-23-2006, 09:45 PM
Hi, Manuel

Yes, we're all talking about the same thing, your illustration is absolute correct. However, please count that all 3 shapes have different geometry but same surface normals. So, maybe, "magic 50%" is not what you need.
Are you saying that the three shapes have different geometry after displacement, but they keep the normals from the geometry before displacement? If so, why would that be a big problem?

AVTPro
04-23-2006, 09:56 PM
Alonzo, you'll see SAME elevations and craters with 50% as they are with 0%, sure :)

No. You can't protrude and extrude at the same time in EIAS. You can't get the full dynamic range at the same time. You can't paint white to move up from the surface then paint black to move below the surface. You are stuck at the surface if you are in positive values. Zero would only stop at the surface if you are in positive range. If you are using a (+) map at (zero) then you can't paint darker than black (0) to unless you change the function values of the image with a minus.

It's limited.

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.

if you slide the nuetrual value of 128 or 50% around to 70% then you limit the range of values the artist can use to describe the surface. Yes, he/she may want to do this but, it should be the artist discretion.

Again Thanks for you input. I'm just trying to be exact not arrogant. Please show me where I am wrong.

Igors
04-23-2006, 10:12 PM
Hello, gentlemen

Let us explain "50% prob" as we understand it. Displacement/bump creates "pits and hills". If displacement direction is inverted, then pits and hills are inverted/swapped too. However, it doesn't happen if you use "50%" instead of "0%" sea level. This operation simply moves "whole terrains" up or down, but hills remain hills and pits remain pits.

With "0%" there are displacement amplitudes: 0.45, 0.50, 0.55. With "50%" for same points: -0.05, 0.00, 0.05. Yes, we changed amplitudes but the differences between them are absolute same. Thus we've same surface bumped normals for both cases, they are calculated based on a difference between points. The results will have different geometrical sizes and a some difference, defined by different displacement amplitudes: more or less portions of surface will be shown/hidden. But "general mimics", defined by normals, are same for both.

Math says that any constant addition doesn't change derivative/differential, here is this case exactly.

Maybe ZB does something other, that's we don't know. But in any case "50% gray" would have usability near zero IMO

manuel
04-23-2006, 11:26 PM
Hello, gentlemen

Let us explain "50% prob" as we understand it. Displacement/bump creates "pits and hills". If displacement direction is inverted, then pits and hills are inverted/swapped too. However, it doesn't happen if you use "50%" instead of "0%" sea level. This operation simply moves "whole terrains" up or down, but hills remain hills and pits remain pits.
Understood, but I didn't think we were talking about inverting displacement maps.

With "0%" there are displacement amplitudes: 0.45, 0.50, 0.55. With "50%" for same points: -0.05, 0.00, 0.05. Yes, we changed amplitudes but the differences between them are absolute same. Thus we've same surface bumped normals for both cases, they are calculated based on a difference between points. The results will have different geometrical sizes and a some difference, defined by different displacement amplitudes: more or less portions of surface will be shown/hidden. But "general mimics", defined by normals, are same for both.

Math says that any constant addition doesn't change derivative/differential, here is this case exactly.

Maybe ZB does something other, that's we don't know. But in any case "50% gray" would have usability near zero IMO
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.

http://www.geocities.com/manuroig/displ-cgtalk2.gif

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.

Reuben5150
04-23-2006, 11:58 PM
3. Any changing of midpoint affects only object's "geometrical size" (like it's bigger with mid 0 and smaller with mid 0.5), but all surface normals remain absolute same. So, we've doubts that another midpoint would make you happy ;-)

Ahh yes, You know and i know.

I wondered when this would come up.


Reuben

Reuben5150
04-24-2006, 12:05 AM
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
04-24-2006, 01:40 AM
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.

http://i47.photobucket.com/albums/f190/AVTPro/EIASDis.jpg

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.

AVTPro
04-24-2006, 01:48 AM
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
04-24-2006, 10:00 AM
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
04-24-2006, 10:18 AM
Hi, Alonzo

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



http://i47.photobucket.com/albums/f190/AVTPro/EIASDis.jpg



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
04-24-2006, 10:23 AM
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
04-24-2006, 10:44 AM
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
04-24-2006, 10:48 AM
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
04-24-2006, 11:04 AM
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
04-24-2006, 11:22 AM
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
04-24-2006, 11:40 AM
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


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
04-24-2006, 12:15 PM
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
04-24-2006, 01:12 PM
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
04-24-2006, 01:59 PM
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
04-24-2006, 03:39 PM
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
04-24-2006, 03:40 PM
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
04-24-2006, 03:50 PM
This is an interesting video about the same subject & file:

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

Cheers

Hans

AVTPro
04-24-2006, 04:09 PM
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
04-24-2006, 04:43 PM
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
04-24-2006, 04:53 PM
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.

Igors
04-24-2006, 04:54 PM
Hi, Uwe
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.

uweYou said nothing wrong, just in our opinion the things have "another focus". Practically human sees what surface normals show him, thus 50% grey would be a very little help here (see posted images).

We also don't share Alonzo's opinion that 16-bit displacement and/or micropolygon displacement would be really helpful for EI user

manuel
04-24-2006, 04:54 PM
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
Have you been able to test this in Modo? It's only 201 that will do it, no? You a beta-tester then?

edit: I guess you've been watching the Modo video then. Very nice BTW how they allow you to set a minimum and maximum displacement: simply set it to -100% and 100%.

bronco
04-24-2006, 06:18 PM
Hi, Uwe
You said nothing wrong, just in our opinion the things have "another focus". Practically human sees what surface normals show him, thus 50% grey would be a very little help here (see posted images).

We also don't share Alonzo's opinion that 16-bit displacement and/or micropolygon displacement would be really helpful for EI user
Hey igors, thanks for your reply.

If i may ask: What is the focus?

i don't really speak about the human perception. as all of you know, it can be cheated soo easily. thats half of the buisness ;)
my concern is mostly accuracy, ease of use and a possible cause for unwanted artifacts.
one map is better than two! :)
if this means simple tone-remapping (like in the modo video) great! the math behind it should be pretty straight-forward (take this with a good amount of salt, as i don't have any clue about programming, hehe).

well i can see where micropoly displacement and 16bit can be usefull.
saying 8bit is enough reminds me a little at the time when 16 mb ram was enough :)

(just half-kidding here. there will allways be projects that call for the least bit available amount of control (really needed or just wanted is another discusion), and why not give this control to the user? otherwise this user will turn to other programs which have the ability, first just for that project and over time completly) just my opinion

AVTPro
04-24-2006, 06:40 PM
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

To be honest, there's no getting around Zbrush. I don't know why anybody could look at the Zbrush Site and not hear the stampede? Like it or not, ZBrush offers a solution for what programs promised but never delivered. A true 3D digital paint and sculpting solution. It works on many levels to the degree, that I was to slow my pursuit of animation just to do digital paints, sculpts as stills. I have been seriously considering only using ZB for the next 3 months.

Yes, Zbrush can teach EIAS a few things about how time waits for no one. Evolve or Die. Life means change. I'm not going to make excuses why I shouldn't be a part of the future. No one in this feild can afford to be bogged down with adverse thinking, words or conditions that stunts growth.

ZBrush has so many uses, I can't begin to count them. It's excellent for morphs targets, texture painting, modeling, on and on. I'm not letting my own biases sabotage myself in an industry that relentlessly reaching higher and wider abroad.

EIAS is not the early train on the ZB railway. We are currently behind on this. With even modelers like Modo supporting the correct nuetral gray displacement paradigm (note it is address before the 16 bit, subpixel is addressed in the video), we can not sit back and deny in the face certain force of foreboding change in the 3D landscape.

Never again will I think adapting to change will take away from my growth as a 3D artist. Resisting change and insisting to live in the past is surely stagnation. Life is change.
Other artist are creating artwork, the likes have never been seen by the old masters.

OK, I will put the megaphone away. I will do test instead of typing.

Fritz, you will need Encage by Igors (konkeptione) and Obj2Fact by Ramjac.
Igors Encage has many uses. They are brilliant programmer. I don't understand they refuse to see our need.

AVTPro
04-24-2006, 06:58 PM
Last thing.

I think subpixel or micropolys, high frequency, 16 bit renders without unified, intuitive nuetral 128 grayscale, dynamic range displacement map is moot.

It should be first.

very last.

Igors are good. I love them. period. :)

AVTPro
04-24-2006, 07:02 PM
I just added the ages of both Igors up :) Let me know if I did the maths right.



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.


yes, feel my pain. Render test on a dual 500 mhz :)

Believe me I know how important this is. It's life changing. I'm hoping to do an artshow over the summer. Return to my painting roots. Only do Zbrush and render in EIAS for a few months. Sit in the park and sell paintings. 'Tis a dream I have.

AVTPro
04-24-2006, 07:17 PM
Hi, Uwe
You said nothing wrong, just in our opinion the things have "another focus". Practically human sees what surface normals show him, thus 50% grey would be a very little help here (see posted images).

We also don't share Alonzo's opinion that 16-bit displacement and/or micropolygon displacement would be really helpful for EI user


Igors I'm not asking for 16-bit renders or micpolys, I'm asking for one unified displacement map workflow in EIAS like all the other programs.

Separating the one map in PS is slow and doesn't work well.

Still I am only asking...ok..pleading, no...begging but trying to be clear at the same time.

Reuben5150
04-24-2006, 07:25 PM
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
:)

Yes i agree, just can't see a light at the tunnel end :argh:


Reuben

Reuben5150
04-24-2006, 08:06 PM
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.



And they all have different ways of handling it i expect, just like HDRI, GI, etc, etc.

Regarding the grayscale "mid-point" or +/- displacement feature, i always think about the way SoftImage handles it, example -

Add a "change range" node -

Settings-

Old range 0.0 to 1.0

New Range -0.5 to 0.5

This is a math node added to the material tree, applied to the displacement map, looks simple huh, but who knows what goes on under the interface :hmm:

I've already shown the Igors a screenshot of this setup, not that its much help, just trying to understand how it works in other apps i guess.

I seem to remember protesting at the suggestion of a plugin or "helper app" to solve the prob, (yes a common moan :) but at this point i'd take it without question, plugin, shader, whatever..

Reuben

bronco
04-24-2006, 08:31 PM
...
I seem to remember protesting at the suggestion of a plugin or "helper app" to solve the prob, (yes a common moan :) but at this point i'd take it without question, plugin, shader, whatever..

Reuben

whatever helps to sort this out.
the best solution would be if EITG includes it into v7. who is resposible for this? matt?
like i already suggested a preference switch would be the best to support older projects.

Reuben5150
04-24-2006, 08:40 PM
I can't agree with you here. (but I'm not a bad guy for that :)



No i think Igors are right, the default adaptive and group uv tile projections are very difficult for the renderer, no bluring, no texture AA is allowed and the alignment has to be so accurate, sure, there are ways around the prob as you have found, but uv mapping the model outside ZB defeats the objective IMO.

There is another mapping method in ZB called simply "uv tile" which produces a seamless uv map, unforunately i found this to be buggy as hell :banghead:

But since this topic came up maybe l'll take another look at ZB and maybe its time to start asking Pixologic for helpfull features and more importantly bug fixes.

Reuben

manuel
04-24-2006, 09:41 PM
yes, feel my pain. Render test on a dual 500 mhz :)

Believe me I know how important this is. It's life changing. I'm hoping to do an artshow over the summer. Return to my painting roots. Only do Zbrush and render in EIAS for a few months. Sit in the park and sell paintings. 'Tis a dream I have.
Return of the undo-less workflow! Bliss.

To be honest, I can't even figure out what this topic is about anymore. All I know is that conversations between artists and programmers can be very, very difficult. We use the same words but talk a different language. For me, the whole conversation is about workflow, but the Igors may be thinking more about implementation.

bronco
04-24-2006, 09:58 PM
All I know is that conversations between artists and programmers can be very, very difficult. We use the same words but talk a different language. For me, the whole conversation is about workflow, but the Igors may be thinking more about implementation.

i think you nailed it down!
i am sure the igors understand completly what we all want, but at the same time do the math:
time to implement the features / (benefit for the programer + benefit for the user) * buzz feature factor = x

as you can see, i know my math :D

Igors
04-24-2006, 10:45 PM
Hello, gentlemen

Yes, the thread looks totally disorganized (Alonzo is here :)). Let us say summary what we think about displ. probs (it's also an answer for Uwe's questions)

- 50% grey. The feature with "micro" eventual effect. We've nothing to add to what we wrote/showed before;

- 16-bits. Actual for terrains with both: mountains and micro-details are created with a single map. For characters etc. 8-bits works quite well. Note: 8-bits does not mean that only 256 displacement values are possible, it's only a range of source map;

- micropolygon displacement. "Hard weight" feature. We are not familiar with its theory, but we know:
- it's not fast itself;
- it has numerous problems with ray-tracing (count GI);

- UV seams. IMO it's the really actual and important problem. Though we don't know either other apps really solved it (quite possible) or only talk they solved (also possible). We've experimented with ZB maps in Max - seams too (but Max renders normal maps seamlessly - we don't know how)

- btw: maya has also adaptive displacement and we like it much more than the micropolygon one;

That's all :)

AVTPro
04-25-2006, 03:20 PM
Yes, the thread looks totally disorganized (Alonzo is here :)).

Whatever Igors. Anytime you want to clean up my apartment...Bring it! LOL

http://i47.photobucket.com/albums/f190/AVTPro/Bringit.jpg

Anyway. Sorry Manuel, I used this forum as an opportunity to request enhancements to EIAS ZB compatablity.

Rueben, I agree. Yes I have found a UV editing workflow that completely eliminates seams and it works very dependably but with more compatablity between EI and ZB it shouldn't be necessary. With AUVs and Zapplink there's no need to UV edit. I only did it because I wanted to paint my texture in PS. Now, with the application linking module in Zbrush, I can.

I still have to check the UV "Fix seams" options to see if AUV works or not. I am not sure right now but regardless, knowing that UVs are conquered and not a real threat to my process...I would hate to see precious programming time put towards something that is not a problem...not at least until I test it or can say for sure.

Lastly, I believe EI can render quality displacemts with an 8 bit render. IMO, It would be enough to deform geometry edges correctly. My concern is displaced geometry edges and why I am not concerned about Bump maps. Bumps maps in EI are fine but without accurately displaced edges bumps look fake. So personally, that is why I am not so interested in precious programming resources put toward changing Cameras quality to 16 bits, microspolys, or bumps.

I am very concerned and am asking that some effort be made to remedy the workflow issue which includes the use of Photoshop to cut up a single greyscale map into halves so that these two separate maps can be loaded into EI as positive and negative values when it should be simply imported into EI and rendered. (whew)

Long as it's simple and fast, I don't care out. One input box for the displacement texture to change the gamut range.

Without out handling this bottleneck first, the rest is inconsquential anyway. I would not care anything about 16 bits or subpixel without this peliminary procedure in producing the correct 16 bits subpixel render effects. Though it would be nice, but who cares if it's not correct or a big hassle with manually converting each test map. I just want my surface edges to be remeniscent of the form.

Yes, Rueben. The other apps all handle the nuetral displacement mid-point grey value differently. Instead of zero it's push up to half but they still have control over each map.
Is it a whole version change when other apps just have a text input? EI 7? golly. No offense, but I hope we dont' need a new release for such old news.

Rueben I will do the pixolator test in Maya and post the number shift.

Thanks for listening everybody...and Igors. :)

Again Rueben I appauld you and all the testing you did. It started to wear me down. Talk about brain-strain.

manuel
04-25-2006, 04:02 PM
Heheh, no worries Alonzo :) keeps things interesting.
I've never used ZBrush, I've stared a few times at the interface and that's about it.
I was thinking the following: at the moment in Animator, you have a setting for the amount of displacement. You could say this the maximum setting. What you really want is a second input-field with the minimum setting. At the moment the minimum setting is always zero (=sea-level). So to create a 50% grey situation, you would type in Min: -0.5 Max: 0.5 and you'd have a displacement of 1. Old project would simply come in with Minimum set to zero. It would also give you a lot of control if you wanted the minimum to be less than the maximum...

Igors
04-25-2006, 07:06 PM
Hi, Alonzo
Whatever Igors. Anytime you want to clean up my apartment...Bring it! LOL We think a person who can clean up your apartment isn't born yet :) The creation of full chaos is not near last in list of your talents. You always write about many themes in one post, some of them are interested, but it's impossible to answer for you, cause you talk about absolute all :)

AVTPro
04-25-2006, 08:17 PM
Hi, Alonzo
We think a person who can clean up your apartment isn't born yet :) The creation of full chaos is not near last in list of your talents. You always write about many themes in one post, some of them are interested, but it's impossible to answer for you, cause you talk about absolute all :)

LOL. Very Funny. Maybe I should be a writer? :)
Someone once told me I was a genuis at messing up my apartment.
I just took what I needed out of her statement. "Genius".
So let's apply this rule to your paragraph. " Hi. Alonzo. Creation. Your Talent. Many Themes. Interested. Absolute All" In other the same words, you are absolutely interested in all the many themes of my talented creations.
I will contemplate on these encouraging words Igors. Thanks.

Anyway, for your benefit I will try to be more focused instead of chaotically bouncing my talent on the many themes of absolutely interesting creation of 3D.

AVTPro
04-26-2006, 12:09 AM
In Maya, using Pixolators video for Mental Ray render

the settings for the nuetral displace offset is an very simple expression in Alpha Offset input box.

there's two input boxes.

Alpha Gain
Alpha Offset

in Alpha Gain you put this.

=-file1.alphaGain/2,

The file number is what your current file name is.
Then any setting in the Alpha Gain, which tells the render how much to push displacement in and out will be offset by negative half.

So yes, Manuel, two boxes to control it is whats needed.

However I can't get mental ray to render a good image yet...don't know what I'm doing wrong. It won't smooth it.

AVTPro
04-26-2006, 12:16 AM
Sucks


MENTAL RAY RENDER DIAGNOSTICS:
Textures
- Filter type of file node "file1" (Quadratic) is not supported.
Performance
- file1 has a resolution of 2048x2048 which may be unefficient.
- If file1 is not a memory mappable file, use imf_copy to convert it to .map format, to improve the performance.
// Warning: 3 warnings, see script editor for details. //

Igors
04-26-2006, 12:43 AM
Hi, Alonzo
In Maya, using Pixolators video for Mental Ray render

there's two input boxes.

Alpha Gain
Alpha Offset

Typically "gain" is what's named as a "falloff" in EI, so we guess it doesn't change displacement direction but only modulates it. But "offset" should (we guess). Can the writer post a several images with different offsets? :)

AVTPro
04-26-2006, 01:15 AM
Hi, Alonzo
Typically "gain" is what's named as a "falloff" in EI, so we guess it doesn't change displacement direction but only modulates it. But "offset" should (we guess). Can the writer post a several images with different offsets? :)


Sorry Igors. The writer is not so ingenius. I haven't got a good render yet from EI or Maya. I guess that's why I am a bit frustrated. I will keep trying. I will let you know if I get anything good. I'm just starting my retesting today.

AVTPro
04-27-2006, 11:37 AM
I'm giving God the Glory for this, because I'm still scratching my head. I don't know why but It's working!

AUVs. No Seams. No Nothing

http://i47.photobucket.com/albums/f190/AVTPro/ProjectPixolPerfect_9.jpg

AVTPro
04-27-2006, 12:11 PM
Not sure what that one spot is, but still this is all far better than before. All I got was the big spots.

I would say this detail is fine for 8 bit...but so was the 16mb of RAM :)

Dealing with PS was a lot easier this time, I think because I wasn't so bombarded with modeling and sculpting. I only had to render this model and so I didn't mind playing with the maps in Photoshop this time. I was still learning ZBrush, so it's was all confusing and tiring last time I tried this. It only two one or two renders to get something reasonable.
OK...guess the party is over.

Now about the wmp maps tearing :) ack!

http://i47.photobucket.com/albums/f190/AVTPro/PixolPerfect_12.jpg

Thanks everyone for helping me get a better understanding.

One key point,
My first render was too undefined. Then I went on the Pixolator site and notice
his map had more contrast. I used levels then it seem to look a lot more
similiar to his.

This would not be possible without in EI without Obj2Fact
www.ramjac.com (http://www.ramjac.com)
and
Encage from Igors.
www.konkeptione.com (http://www.konkeptione.com)

and

God

:)

AVTPro
04-27-2006, 12:23 PM
The flat spots may come from conversions? Can't say unless there were no photoshop conversion involved, (which is that I perfer).

I didn't do a best test, just getting it to work.

http://i47.photobucket.com/albums/f190/AVTPro/samedeal.jpg

manuel
04-27-2006, 12:30 PM
Did you clip the whites or blacks a bit when adjusting the levels in Photoshop? Looking good though. What was the subdivision level in Encage?

AVTPro
04-27-2006, 12:46 PM
So you have your low res in EIAS and the Camera renders the hi-res with Encage. This is good functionality. ( when it works :)
I couldn't open the Obj to convert it into a Fact file without O2F. EI wouldn't see it, but I didn't try Transporter.


Last one. I gotta go look for a tree in the shade :)
Just kidding, not going to stop animation but still would like to do paintings.

Thanks again ALL. It's good I complain before I make it work else I wouldn't talk about the problem. I hope it works as good on my models now (?)

http://i47.photobucket.com/albums/f190/AVTPro/shade.jpg

AVTPro
04-27-2006, 01:23 PM
Did you clip the whites or blacks a bit when adjusting the levels in Photoshop? Looking good though. What was the subdivision level in Encage?

It must have...but the levels adjusted I added had everything to do with the sucessful displacement.

I think also the artist who made the maps, really knew what he was doing.

I used 3, then 4 was the final. However it looked OK at the defaults. and Thanks.

AVTPro
04-27-2006, 01:54 PM
Hi, Alonzo

[/center]
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 thanks for taking the time

AVTPro
04-27-2006, 10:29 PM
As Igors said, there may be advantages for have a separate positive and negative map. If we keep it and add one check box to switch the gray value range so we can use a single map, so we can decide which to use. This way, a greyscale image can be paint in photoshop (ligh and dark with gray as base).

Again, I think this whole thread shows how "Top Notch" EI Users are passionate, knowledgeable, considerate and most of all, helpful. Thanks, it good to know you guys around. I in someway, this thread helps other EI users.

I want to post one more image testing on something I have modeled.

manuel
04-28-2006, 10:36 AM
I'm not too sure they were saying that there were advantages to using two maps. Just that one map isn't going to solve all your problems.

AVTPro
04-28-2006, 12:07 PM
Definitely won't solve my money problems :)

But I would settle for workflow problems. However I agree, It's only one step in the process.

Igors
04-28-2006, 02:25 PM
Hi, Alonzo, Manuel
I'm not too sure they were saying that there were advantages to using two maps. Just that one map isn't going to solve all your problems.Ahhaa, we see artists can understand developers very well :) Of course, it's affair of artist how many maps he needs, so, as minimum, we never said he shouldn't use 2 or more maps.

About EI+ZB: be honest, we don't know where is "bottleneck" here. The "turtle head" Alonzo showed looks impressive, but, unfortunately, not all from ZB is going so successfully. We've uploaded an old archive on EI beta server: 6.5\Images and Renders\Igors\Simple-Bias1.sit. It was prepared by Reuben (as we remember, sorry if not). Our idea was to see/check EI/ZB compatibility by using a simple cube example. The result is "full fiasco" (of compatibility). First we see no way to map image as in ZB :sad: Second - bloody seams :eek: . We are confused, cause, as we understand, with such map a normal render SHOULD be seamed. We've checked it with Max and Maya - yes, seams too. We are also confused that incoming map has no any hints/additional info that can be used to fix (like, say, a mask alpha channel)

AVTPro
04-29-2006, 04:08 AM
About EI+ZB: be honest, we don't know where is "bottleneck" here. We've uploaded an old archive on EI beta server: 6.5\Images and Renders\Igors\Simple-Bias1.sit. Our idea was to check EI/ZB compatibility by using a simple cube example. First we see no way to map image as in ZB :sad: Second - bloody seams :eek: . We are confused, cause, as we understand, with such map a normal render SHOULD be seamed. We've checked it with Max and Maya - yes, seams too. We are also confused that incoming map has no any hints/additional info that can be used to fix (like, say, a mask alpha channel)

First I want to say thanks Igors for the comment about the turtle head (LOL)
and second for sharing your concerns and frustration about programming issues.

I'm going to see if this will works again with other models soon.

So I want to cross reference something I wrote in postforum. I'm going to try to keep future discussion in this forum to avoid disorganization :)

http://www.postforum.com/forums/read.php?f=9&i=40916&t=40901

Again, I'm a fresh Zbrusher so it doesn't mean I'm 100% sure about anything but the image says I'm not completely wrong either hha.

Bottom line, I think seams are user error and not program error and I don't think micropoly or 16 bit is pivotal to good or expressive renders. I think EIAS being able to use a single displacement map
for positive and negative is most important for artist.

I wish people did not see adaptive mapping as the only Zbrush technique for mapping. It's just very fast and simple if it works. I believe that AUV is like reqular UVs you have to learn to perfect it. Else there wouldn't be so many options to fix it in Zbrush like "Check UVs, Fix Seams and Smooth UVs" I think EI users just need to learn the options to make AUV if that's the type of UV mapping you chose. There's no seam in the Pixolator AUV "Turtle Head" because the Artist knew how to make maps without seams. I choose to use GUV because I can put one seam and control image. AUV is nice but you can't look at the map in PS and say I want to fix this area...it's only squares.

So this is also why I made a "royal change of mind" about two maps oppose to one map. I think it's still better to have one map..but if you still need to bring it in PS to edit the single map, the 5 extra minutes to separate with Lolo's curves is not so bad. Once....but if you have to do it lots of test renders then. 5 mins * 10 tests = one hour of extra time and headache.

This is the bottleneck but it is only the most obvious one that should be solved first. It's solves problem of loading separation curves in PS, then reload two maps setting in EI displacement. There's confusion in this process double map when you edit one displacement setting. Do you also have to change both positive and negative to make a change in the image? positive or negative or both? Then what happens if you just change negative? So you must carry problem not just in PS but over to EI. And longer you carry problem, the heavier it gets :)

http://i47.photobucket.com/albums/f190/AVTPro/AVT_Pixolator_test.jpg

AVTPro
05-01-2006, 11:15 AM
So this is the culprit that sent me down the Zbrush path. I didn't want to model the craters by hand. Call me lazy. haha.

Special thanks to LOLO

http://i47.photobucket.com/albums/f190/AVTPro/ManhattanMoonMan.jpg

The door is swinging wide open on this one now. Mission Accomplished!!
It will be good to use my favorite renderer with Zbrush

BTW, wasn't going for super high res...just craters and textures without smears.

Reuben5150
05-01-2006, 12:51 PM
We've uploaded an old archive on EI beta server: 6.5\Images and Renders\Igors\Simple-Bias1.sit. It was prepared by Reuben (as we remember, sorry if not). Our idea was to see/check EI/ZB compatibility by using a simple cube example. The result is "full fiasco" (of compatibility). First we see no way to map image as in ZB :sad: Second - bloody seams :eek: . We are confused, cause, as we understand, with such map a normal render SHOULD be seamed. We've checked it with Max and Maya - yes, seams too. We are also confused that incoming map has no any hints/additional info that can be used to fix (like, say, a mask alpha channel)

Hi Igors,

Regarding that simple-cube-test, if i remember correctly i had problems with the texture alignment, probably due to the fact the model was converted on a PC, there is still an outstanding issue here, but i upoaded the prj anyway.

IMO the only way to convert the Zbrush models is with OBJ2Fac2 on a mac, all other methods destroy the texture quadrangle which means you have to try and align the texture "by hand" or input the values, its hit-and-miss.. 95% miss unfortunately.

Whats the problem ? i don't have a Mac !!!

Today i will fire up Zbrush for a new test.

Reuben

AVTPro
05-01-2006, 07:33 PM
I said was going to look at this after I did my test. I saw your original beta test report.
I couldn't figure out why you were having problems with placement, especially with UVs. This is what I found.

http://i47.photobucket.com/albums/f190/AVTPro/RuebensCube.jpg

No problem with placement or seams.

I didn't separate the maps in PS, I think that is where the banding is coming from,but it's not seams.

If you have a model you need converted let me know Rueben's let me know.

Igors
05-02-2006, 12:49 AM
Hi, Reuben, Alonzo
I couldn't figure out why you were having problems with placement, especially with UVs. This is what I found.

No problem with placement or seams.


Hmm.... Alonzo, please upload this prj to us (into our folder on EI beta site or give us another link). Let us first learn, then talk:)

IMO the only way to convert the Zbrush models is with OBJ2Fac2 on a mac, all other methods destroy the texture quadrangle which means you have to try and align the texture "by hand" or input the values, its hit-and-miss.. 95% miss unfortunately.For normalized UV's it's not a big problem to calculate scales manually. Hmm.. maybe it would be interested to re-check a sword model you rendered?

AVTPro
05-02-2006, 03:30 AM
Hi, Reuben, Alonzo
Hmm.... Alonzo, please upload this prj to us (into our folder on EI beta site or give us another link). Let us first learn, then talk:)

For normalized UV's it's not a big problem to calculate scales manually. Hmm.. maybe it would be interested to re-check a sword model you rendered?


[/left]
[/center]


Do you mean my project ? It's the same project file that's up there now. I got it this morning. I just looked up in the thread, followed it and it was still there.
--
We've uploaded an old archive on EI beta server: 6.5\Images and Renders\Igors\Simple-Bias1.sit.---

Or do you want my project I just converted? NO WAY! EIAS works fine. I don't want you to change anything in EI except single mapping. Not until you fix the Weight Map "Tearing" Problem. Encage is not a solution for weight tearing in character skins. I can't rig my characters anymore. You have to fix it first! Then I give you my project file. :)

Just kidding. I know that's not the proper way to get a bug fix. You can have the project...long as it's just a fix for PC. Works fine on the Mac.

I will put it in the same folder....but if you happen to see any tearing weight maps on your way...Help a crazy character out.

yhloon
05-02-2006, 04:51 AM
Hi Igors,

Regarding that simple-cube-test, if i remember correctly i had problems with the texture alignment, probably due to the fact the model was converted on a PC, there is still an outstanding issue here, but i upoaded the prj anyway.

IMO the only way to convert the Zbrush models is with OBJ2Fac2 on a mac, all other methods destroy the texture quadrangle which means you have to try and align the texture "by hand" or input the values, its hit-and-miss.. 95% miss unfortunately.

Whats the problem ? i don't have a Mac !!!

Today i will fire up Zbrush for a new test.

Reuben

Hi Reuben

I've no problem (at the moment) to bring UV in to EI, not even the position problem, and I'm using PC without O2F, the trick is use the whole UV space... I mean occupy the 4 edges of the UV space.

for instance, a UV unwrap of a cube, where there is space at the top and the bottom of the space...this will cause position problem in EI
http://i30.photobucket.com/albums/c336/yhloon/UVmap/UV01.jpg

move the UV or scretch it to 'touch' the edges...than export to obj file convert to fact format with transporter (uncheck all the check box) that should fix the position problem...
http://i30.photobucket.com/albums/c336/yhloon/UVmap/UV02.jpg

Reuben5150
05-03-2006, 12:49 AM
I said was going to look at this after I did my test. I saw your original beta test report.





If you have a model you need converted let me know Rueben's let me know.





Do not pay too much attention to those old writtings and early tests, some opinions have changed since then.

Yes some model conversions would be helpfull.

Reuben

Reuben5150
05-03-2006, 12:57 AM
For normalized UV's it's not a big problem to calculate scales manually. Hmm.. maybe it would be interested to re-check a sword model you rendered?


[/left]
[/center]

I seem to remember you telling me this, could you give an example of caluclation ?

Yes i can look at that project again, that was designed by "Pixolator" to be a stress test
for sub-pixel renderers.

Reuben

Reuben5150
05-03-2006, 01:25 AM
Hi Reuben

I've no problem (at the moment) to bring UV in to EI, not even the position problem, and I'm using PC without O2F, the trick is use the whole UV space... I mean occupy the 4 edges of the UV space.

move the UV or scretch it to 'touch' the edges...than export to obj file convert to fact format with transporter (uncheck all the check box) that should fix the position problem...


Hi Loon,

Yes i read did read the documents you sent me ;)

I agree on using the whole of the uvspace makes for easy texture alignment, problem is Zbrush has no option to do this (that i am aware of) so yet again we are back to uv mapping outside of zbrush which brings more problems and defeats the object of AUV an GUV mapping.

The whole point of zbrush AUV and GUV mapping is that
1 it provides almost distortion free texture mapping.
2 it is automatic, no need for manual editing which is not a pleasant task IMO.

No amount of fiddling with transporter settings has provided a "perfect"
conversion, texture quadrangle is always triangulated :hmm:

Simple test, load a model made up of 100% quads, in transporter it will report for example
3000 quads, export the model and load into EI, look at model info you will see reported 2999 quads and 2 triangles.

This does not happen with OBJ2Fac2, thats why your textures are auto-aligned correctly and correct alignment is all-important where AUV and GUV are concerned.

Under these conditions "seems" are not a problem.


Reuben

Reuben5150
05-03-2006, 01:54 AM
IMO the only way to convert the Zbrush models is with OBJ2Fac2 on a mac, all other methods destroy the texture quadrangle
Reuben

Actually thats not 100% true, the "sword test" just reminded me, Polytrans does convert with the texture quad intact, but it also brings other problems.

R

Igors
05-03-2006, 03:09 AM
Hi, Reuben
I seem to remember you telling me this, could you give an example of caluclation ?

Yes i can look at that project again, that was designed by "Pixolator" to be a stress test
for sub-pixel renderers.

For normalized UV simply set scales like 1.0/map_size_x and 1.0/map_size_y

Maybe (it's our assumption only) importers have problems with different UV saving in EI and other programs. UV's are always x,y,z triple, but in EI they are stored per each vertex (often importer needs to create more vertices for UV seams). In other programs they are stored as a "map data" for each polygon, for example a triangle facet refers to 3 UV's. Again, it's just an assumption.

Generally the situation with UV's is a bit funny:) We hear declarations (mainly from Alonzo) that "all is OK", but same time "EI cannot.. etc." We asked for prj to see - no way. So, what we should think?

manuel
05-03-2006, 01:35 PM
move the UV or scretch it to 'touch' the edges...than export to obj file convert to fact format with transporter (uncheck all the check box) that should fix the position problem...
So is that the trick when using UV's? I've been trying Hexagon over the last few days with very little success. In my infinite naivety I thought that UV space in every program works in the same way. I guess I should have known better.

Reuben5150
05-04-2006, 12:14 AM
I said was going to look at this after I did my test. I saw your original beta test report.
I couldn't figure out why you were having problems with placement, especially with UVs. This is what I found.



http://i47.photobucket.com/albums/f190/AVTPro/RuebensCube.jpg


No problem with placement or seams.




I didn't separate the maps in PS, I think that is where the banding is coming from,but it's not seams.

Are you saying you simply opened the project and this was the result ?, or maybe switched between "front" and "user" projections ?, did the map auto-align ? and did you have "normalize" uv on or off ?

Or just upload the project like Igors says PLEASE :)

Your results tell me there is somthing more wrong on the PC.

R

yhloon
05-04-2006, 03:06 AM
Hi Loon,

Yes i read did read the documents you sent me ;)

I agree on using the whole of the uvspace makes for easy texture alignment, problem is Zbrush has no option to do this (that i am aware of) so yet again we are back to uv mapping outside of zbrush which brings more problems and defeats the object of AUV an GUV mapping.

The whole point of zbrush AUV and GUV mapping is that
1 it provides almost distortion free texture mapping.
2 it is automatic, no need for manual editing which is not a pleasant task IMO.

No amount of fiddling with transporter settings has provided a "perfect"
conversion, texture quadrangle is always triangulated :hmm:

Simple test, load a model made up of 100% quads, in transporter it will report for example
3000 quads, export the model and load into EI, look at model info you will see reported 2999 quads and 2 triangles.

This does not happen with OBJ2Fac2, thats why your textures are auto-aligned correctly and correct alignment is all-important where AUV and GUV are concerned.

Under these conditions "seems" are not a problem.


Reuben


:eek:
that will make me reconcider to get myself Zbrush, let see how silo 2 handle UV wit fact format :)...

yhloon
05-04-2006, 03:28 AM
So is that the trick when using UV's? I've been trying Hexagon over the last few days with very little success. In my infinite naivety I thought that UV space in every program works in the same way. I guess I should have known better.

at least it works in EI, I've test UV from Blender, Wings, and sometimes Cineme 4d, but EI handle UV different with others...just like igor said:

EI they are stored per each vertex (often importer needs to create more vertices for UV seams). In other programs they are stored as a "map data" for each polygon

But if you need to use Encage with UV model (via obj to transporter) you will face triangualte problem (even though the source obj is all quad, espcialy on complex model), as what Rueben has mention...so...

1. use hirez UV model (obj) tru transporter, without Encage (try you luck :) )

2. export UV model to fbx, it works all the time with encage, but I did't test it enough,
I won't say this is total solution...


Loon

AVTPro
05-04-2006, 03:45 AM
Are you saying you simply opened the project and this was the result ?, or maybe switched between "front" and "user" projections ?, did the map auto-align ? and did you have "normalize" uv on or off ?

Or just upload the project like Igors says PLEASE :)

Your results tell me there is somthing more wrong on the PC.

R
[/left]
[/center]

Hey I wasn't getting notification about you guys still posting here. I will try to be more attentive.

OK. I have a couple of things to say. First Ruebuen sorry I lost my connection on the beta server.

I will try to keep it short.

1. I'm going to do a free tutorial explaining what works for me. I think we all agree, it is working here. Those are plain EI renders and I'm not cleaning up seams in PS. It works with UV editing and I have a tutorial called "No seams" that proves it. It's a simple, conventional solution. Zbrush Pipeline uses the same workflow (I think?).

2. The flat area is something I did wrong in PS. I clip the levels or image data in PS. It's not a real problem. Sorry I haven't done more tests.

3. The problem Rueben is having with UV placement is very different issue than AUV seams. Yes, the image I postrf of the cube is exactly what I got the first time, no adjustement. User setting but it would work the same with Front. I didn't even divide the maps. I just put the single map bump/displacement at (+)1. The placement is always perfect straight from ZB. There were no seams as well.

4. However, I didn't save the project somehow and when i tried it again, I didn't have the same settings and got seams. Very small, but they were there this time. However, this is what I expected, and still follows my theory that you have to know the right setting in ZB inorder not to get seam. The pixolator head had no seams and if anybody render it, the should have the same results. I was suprised not to get seams the first time with Rueben's cube, because I didn't think Rueben used the settings I believe to be for fixings seams with AUVs.

5. I did a new test with new setting and didn't have any seams directly from ZB. I never have UV placement problems directly from ZBrush via O2F. I will publish in the free tutorial. I was hoping to do more testing with AUV but my UV editing setup works. To do AUVs is merely for the benefit of other users.

6. Lastly, Rueben is correct, AUVs are faster and requires no UV editing in any outside program. However, it's not a traditional workflow (IMO and there are drawbacks or cons to it as well. There are more benefits to manual UV editing, depending on the situations (speed and deadlines). UV editing is more to learn but once you know its very fast and other programs have a Auto Mapping functions as well. With Pelting in most apps, UV editing only takes minutes. I highly recommend anybody doing texture painting, should have one conventional UV editing workflow that works for them.

7. I will do the tutorial as fast as I can. Please give me a week. My original goal for my studies was UV editing, not really ZB. It just happen to be an unexpected bonus that UV editing also worked for ZB. Actually no, I could see how reducing seams would work for ZB. AUV is obviously more problems. GUV is better than AUVs because it doesn't separate every face into a map. GUVs keeps faces as a group and you get less seams to control. I would like to learn more about AUVs so I can do one full tutorial for all EI users.

manuel
05-04-2006, 10:12 AM
at least it works in EI, I've test UV from Blender, Wings, and sometimes Cineme 4d, but EI handle UV different with others...just like igor said:



But if you need to use Encage with UV model (via obj to transporter) you will face triangualte problem (even though the source obj is all quad, espcialy on complex model), as what Rueben has mention...so...

1. use hirez UV model (obj) tru transporter, without Encage (try you luck :) )

2. export UV model to fbx, it works all the time with encage, but I did't test it enough,
I won't say this is total solution...


Loon
Okay, I feel like weeping now. You say that the only way to create a texture for a low-res model, to be used with Encage, is by importing your models in FBX format? Which modellers out there can even save directly in FBX? MotionBuilder costs over 4000$ these days, a bit steep if you're just going to use it for translating models.

yhloon
05-04-2006, 11:29 AM
Okay, I feel like weeping now. You say that the only way to create a texture for a low-res model, to be used with Encage, is by importing your models in FBX format? Which modellers out there can even save directly in FBX? MotionBuilder costs over 4000$ these days, a bit steep if you're just going to use it for translating models.

Free Wings3D :)

manuel
05-04-2006, 11:44 AM
So, import from Hexagon, Silo or Modo into Wings as an OBJ with UV's and then export as FBX with all the UV's still intact? Sounds like a long way around and lots of things may go wrong. Oh well, that'll be another weekend of experimenting and frustration :)

yhloon
05-04-2006, 12:52 PM
:)
that is what i've gone tru, I hope i can do more test, but just switch to a new company, work almost 18hours a day :(

Good Luck

Loon

Igors
05-04-2006, 01:07 PM
Hello, gentlemen

1. AFAIK all apps USE uv's in same way, but STORE/SAVE uv's in different ways. That's what we talked about.

2. Alonzo, here people say like: "it's better 1 time to see instead of 100 times to hear", so a link to prj (you modified) would be wanted. User needs "open-render-result", in worst case "copy-paste-result". If it does not happen, then it does not work, no matter what you and we write

3. That's fully clear that texture should be aligned properly and seams are organized in order to hide them maximally, but we've doubts that seams are processed enough well even with all correct data

Reuben5150
05-04-2006, 11:36 PM
But if you need to use Encage with UV model (via obj to transporter) you will face triangualte problem (even though the source obj is all quad, espcialy on complex model), as what Rueben has mention...so...

Loon

There is no problem with Encage + uv's + lo-res cage AFAIK.

Just to clarify the triangulation problem, it happens with uv'mapped models converted with Transporter (with PC version, don't know about mac) and it is the "texture polygon" or what we normally call the "uv space", this 1x1 square area is actually a polygon and its saved along with the uv data in the model file, but Transporter triangulates this polygon on export, so (i'm guessing) it means EI cannot auto-align textures to the uv layout cause it cannot "see" the texture poly anymore.

Again, i think obj2fact2 is the only way to get a good conversion and i'm only making this assumption based on test projects provided by Mac users.

Reuben

yhloon
05-05-2006, 02:10 AM
There is no problem with Encage + uv's + lo-res cage AFAIK.
Reuben

for me there is a ploblem... I'm no good in english explanation...
maybe I'll post something this weekend...

Loon

manuel
05-05-2006, 12:50 PM
Well, looks like Modo 201 also supports FBX both for import and export. I'll be testing the 103 demo out this weekend. I really am warming to Modo after Hexagon 2.

http://forums.luxology.com/discussion/topic.aspx?id=6641&page=0

Reuben5150
05-05-2006, 11:42 PM
Well, looks like Modo 201 also supports FBX both for import and export. I'll be testing the 103 demo out this weekend. I really am warming to Modo after Hexagon 2.

http://forums.luxology.com/discussion/topic.aspx?id=6641&page=0

Alias does have standalone fbx converters btw.

hmm yes Hexagon2 was rather an anti-climax after the 30 hour download LOL !

Reuben

AVTPro
05-06-2006, 02:26 AM
http://homepage.mac.com/avtpro5/.Public/Project%20Pixol%20Perfect.prj.sit


Here's the Pixolator head project I tested. You can render it and test it for yourselves. See if I'm just making it up.

I have been getting a bit of static about this Zbrush mapping stuff from other users. All I can say is it works for me. I'm using Zbrush, I get no seams. If you have a better method, use it. My method is a traditional, common workflow. "Map out your UVs". It's a standard practice taught by Gnomon. It works as expected when utilized properly. Don't get bothered with EIAS, ZB or me, if you dont' use it. If you feel AUVs are better then use them. But don't blame EI if it's not worth it to use something that's been proven to work with the several images I posted. Seeing is believing.

So officially stating...

The method of manually editing UVs works. Pupil in his UV painted cybersuit works. The moon I post has no seams and works. All my studies, in modeling, rigging, texture editing and animation with EIAS has been successful to me. Even better than I expected.

The pixolator head, Uses GUVs. There's no seams.
I recomment UV Groups, and possible GUVs.
AUV I was never interested in because you can't edit your maps in Photoshop.
However, ZB which I believe to be the cause of seams has setting to resolve it.
It's called Fix Seams under Texture. You can also see the seams in ZBrush when you
click "Check UVs"

You can move the seams around or try to mend them with "AdjU/V". Zbrush wouldn't have all this FIX AUV options if it was just EI. Other Maya users have the same problem.

http://forums.cgsociety.org/showthread.php?t=346367&goto=newpost

ZBrush documentiation says the problem exist in how apps handle UV space. It sometimes makes slit that won't texture.

So I'm going to do one tutorial of how it works then do a supplement how to help the other two methods AUV/GUV.

All'n All, there no seams in the pixolator head, it' uses GUVs. I believe it's mainly a matter of Zbrush expertise. If it was EIAS alone. It wouldn't render. That renders. Test it.

Igors
05-06-2006, 08:25 AM
Hi, Alonzo
http://homepage.mac.com/avtpro5/.Public/Project%20Pixol%20Perfect.prj.sitThanks, but this model/map is a lucky case, it rendered quite well in EI a year ago. We asked about the cube you posted, its moire tell us about very low texture's sampling/blur - otherwise seams are here. No problems if you cannot post a project, we don't want to insist

The pixolator head, Uses GUVs. There's no seams.
I recomment UV Groups, and possible GUVs.
AUV I was never interested in because you can't edit your maps in Photoshop.It would be nice if you explain a difference between AUV and GUV (a little images would be wanted). We are not familiar with these terms and still think AUV = Alonzo's UV's :)

However, ZB which I believe to be the cause of seams has setting to resolve it. It's called Fix Seams under Texture. You can also see the seams in ZBrush when you click "Check UVs"Hmm... interesting. And how this fixing works?

ZBrush documentiation says the problem exist in how apps handle UV space. It sometimes makes slit that won't texture.We've no idea what is a choice here and how a renderer should handle UV "in other way". The subject of render is a polygon. For each rendered point the final texture value (a pixel of image) is calculated with interpolation of texture values in polygon's vertices. These values are calculated based on map's settings (scale, rotate, map type etc.) and vertex position. This position is either original vertex position (in model space) or its UV coordinate if uv mapping is on. So, UV's are just "virtual" vertices positions are used for texturing. Thus we don't understand talks about "this" and "that" UV's :)

AVTPro
05-06-2006, 12:05 PM
Hi, Reuben


For normalized UV simply set scales like 1.0/map_size_x and 1.0/map_size_y

Maybe (it's our assumption only) importers have problems with different UV saving in EI and other programs. UV's are always x,y,z triple, but in EI they are stored per each vertex (often importer needs to create more vertices for UV seams). In other programs they are stored as a "map data" for each polygon, for example a triangle facet refers to 3 UV's. Again, it's just an assumption.

Generally the situation with UV's is a bit funny:) We hear declarations (mainly from Alonzo) that "all is OK", but same time "EI cannot.. etc." We asked for prj to see - no way. So, what we should think?


Didn't say everything was Ok. I said I didn't have a problem with the renders I posted.
If I did have a problem I stated that as well. I spent all nite the other nite debating with another user the pros and cons of each UV mapping set-ups, (AUV, GUV, UVGroups). They are all different and offer benefits and drawbacks.

I only recommend UVGroups. that's the one I subscribed to and plan to use. However, I did a couple test renders in the other methods and initiately didnt have any problems, specifically the Pixolator head.

GUV: because of the seamless grouping of UV is less prone to have problems. Logically, in practice, if seams are causing problem for many artist, the obvious solution to me is to reduce seams. UVGroups or Unwrapping in a UV editor allows for seamless UV blending. Traditional UV editing affords control of the texture texture surface in several ways AUVs can not.

GUVs and UVGroups are not the same. AUVs and GUVs are not the same. GUVs are a cross or middle ground between UVGroups and AUVs. They do hold some UVs together.
The Pixolator held is GUVs. For some reason it works. That reason I strongly believe to be proper settings under the texture menu by a highly talented Zbrush artist. Test it yourself, if it was an EI problem, then it wouldn't render.

AUV: I never agreed with this approach. It's no "be all" premiere workflow. The maps or UVs can't be manipulated visually. It's a completely mechancal process onto itself and the computer outside of Zbrush. The only mechanisms for editing of AUVs in ZBrush and it's limited (under texture menu). It's good if you are only in Zbrush but can cause many problems outside Zbrush. Even with Zapplink in Photoshop, it's inherently flawed because it's reverting to projection mapping agian..and that means smears. Editing Unwraps won't smear.

AUVs only allow for editing and painting in Zbrush where as Unwrapping UV offer both Zbrush, Photoshop tools such as Paths and filters, as well as ZappLink.

To say, Maya or Max can do AUVs but EI can't? Let's see...what else can Maya do that EI can't?

My conclusion is that AUV is a less precise and flexible workflow. Traditionals UV editing is a better workflow. However Zbrush is an excellent interface for 2.5 painting.

Again another misconception ZBrush is not a true 3D app with full 3D viewports. It's 2.5 D with only one 3D object viewport.

Sorry, not blaming you guys but I want to be clear about what I said and did not say.

AVTPro
05-06-2006, 12:46 PM
Igors:

They say it's the handling for UV space between apps. I don't quite agree, because it implies that Zsphere models can't have seams. Seam can appear in Zbrush on internally generated models.

So my questions why does Zbrush separate the UVs? Does the render mend the UV back together? or is embedded in the polygon? You can move a UV anywhere and it will paint the poly the same. So why aren't the UV's fixing themselves back on the polyface correctly? Is ZBrush separating the polygon faces as well as the UVs? How do you close the gaps, besides the controls listed below. How does Maya and SoftImage place the UVs. Is there a coordinate missing in the UV or EI map data?

http://i47.photobucket.com/albums/f190/AVTPro/SlitsandSeams.jpg

Does Pixologic make it's UV specifications available for other renders? Where is it?

AVTPro
05-06-2006, 01:10 PM
Hi, Alonzo
Thanks, but this model/map is a lucky case, it rendered quite well in EI a year ago. We asked about the cube you posted, its moire tell us about very low texture's sampling/blur - otherwise seams are here. No problems if you cannot post a project, we don't want to insist

It would be nice if you explain a difference between AUV and GUV (a little images would be wanted). We are not familiar with these terms and still think AUV = Alonzo's UV's :)

Hmm... interesting. And how this fixing works?

We've no idea what is a choice here and how a renderer should handle UV "in other way". The subject of render is a polygon. For each rendered point the final texture value (a pixel of image) is calculated with interpolation of texture values in polygon's vertices. These values are calculated based on map's settings (scale, rotate, map type etc.) and vertex position. This position is either original vertex position (in model space) or its UV coordinate if uv mapping is on. So, UV's are just "virtual" vertices positions are used for texturing. Thus we don't understand talks about "this" and "that" UV's :)

Sure, Igors glad to provide any information that will help. I will show pics and samples, or projects.

Yes, that's right blurring was off. So I will redo, Ruebens cube. It work first time but I didn't save project, then it didn't work again as good.

Igors
05-06-2006, 02:06 PM
Hi, Alonzo

They say it's the handling for UV space between apps. I don't quite agree, because it implies that Zsphere models can't have seams. Seam can appear in Zbrush on internally generated models.

So my questions why does Zbrush separate the UVs? Does the render mend the UV back together? or is embedded in the polygon? You can move a UV anywhere and it will paint the poly the same. So why aren't the UV's fixing themselves back on the polyface correctly? Is ZBrush separating the polygon faces as well as the UVs? How do you close the gaps, besides the controls listed below. How does Maya and SoftImage place the UVs. Is there a coordinate missing in the UV or EI map data?
Does Pixologic make it's UV specifications available for other renders? Where is it?We wrote:
UV's are just "virtual" vertices positions are used for texturingWe are sure it's fully true, and, AFAIK, any renderer processes UV's in same way. But any renderer does not calculate UV's, it always uses UV's are stored in model (storage can be in different formats as discussed before). Thus a fact of "UV's presence" doesn't promise nice results yet, all depends from how lucky they are prepared by app/tool is responsible for their creation (and, of course, they should correspond to map image). Up to now we don't understand what do you want from EI renderer cause it processes UV's normally, as any universal renderer should do this.

We understand that AUV, GUV etc. are different techniques of UV's creation. But we are not familiar with details. A simple screenshots/images (one per each approach) would be nice to see

yhloon
05-06-2006, 03:49 PM
http://i30.photobucket.com/albums/c336/yhloon/UVmap/TestUV_2.jpg

an image show how different the transporter fact and fbx...after encage sub-D, it won't happen all the time, but it is quite annoying

Loon

Reuben5150
05-06-2006, 04:04 PM
Sure, Igors glad to provide any information that will help. I will show pics and samples, or projects.

Yes, that's right blurring was off. So I will redo, Ruebens cube. It work first time but I didn't save project, then it didn't work again as good.

Alonzo, i would forget about the cube project, it will only complicate your test results because EI cannot auto-align textures to that model.

We have seen a good working example (the primitive-man-turtle-head:) this is nothing new though, now i think we need a new project, something simple like the cube using GUV tiles since this was how turtle-head was mapped, and then converted with obj2fac2.

As pointed out by Malcolm recently, we've all had some degree of success with EI+ZB, but the problem is inconsistent results, or like "sometimes it works sometimes it don't".

You need to try and reproduce what does work.

I might be able to help out a bit, but until there is means of an accurate model conversion on PC its poinless me providing projects IMO.

Reuben

Reuben5150
05-06-2006, 04:13 PM
http://i30.photobucket.com/albums/c336/yhloon/UVmap/TestUV_2.jpg

an image show how different the transporter fact and fbx...after encage sub-D, it won't happen all the time, but it is quite annoying

Loon

I agree there is a problem with transporter but i wasn't aware of this, it really needs sorting out cause at this point in time PC users are stuffed :banghead:

Have you asked Blair about this ?, i seem to remember asking about the texture polygon triangulation problem, no reply....

Reuben

Reuben5150
05-06-2006, 04:48 PM
Hi, Alonzo

We understand that AUV, GUV etc. are different techniques of UV's creation. But we are not familiar with details. A simple screenshots/images (one per each approach) would be nice to see
[/left]

About AUV tiles, taken from zbrushcentral.com -

Hi http://206.145.80.239/zbc/images/smilies/smile.gif
The UVTiles texture mapping method (which was first introduced in v1.5) has several benefits over other traditional mapping methods. The main strength of the UVTiles method is the capability to automatically map a 2D texture to an arbitrarily-shaped 3D mesh without requiring the artist to spend valuable time in manually assigning (or editing) UV coordinates. The UVTiles method divides the texture to equally-sized tiles which are individually assigned to each of the polygons.
http://209.132.69.82/zbc_uploads/user_image-1039927307nma.jpg

The next ZBrush version (v2) will add another UVTiles-mapping mode which retains the benefits of UVTiles with added capability for variable level of texture-details. This mapping method, AUVTiles (Adaptive UVTiles), assigns texture-tiles that are proportional in size to their target polygons.The following image is an example of AUVTiles-vs-UUVTiles (both 3D objects have been rendered with identical texture-size). A slice of the AUVTiles texture map is shown on the left and contains adaptive-size tiles while the UUVTiles slice on the right consists of unified size tiles.
http://209.132.69.82/zbc_uploads/user_image-1039942965aux.jpg

More information about AUVTiles will be available when it is finalized,meanwhile, if you are interested in testing the compatibility of the current state of AUVTiles mapping with your other 3D applications, you may download the following files...


Click here to download the OBJ (geometry and UV cords) file. (http://206.145.80.239/zbc/zb_memberdownload.php?getfile=PixZSphere50o.zip)

Click here to download the texture map. (http://206.145.80.239/zbc/zb_memberdownload.php?getfile=PixZSphere50b.zip)


Notes:

1. The included mesh and texture are rendered properly in ZBrush even while in preview mode. In some of the other 3D applications (which may be utilizing OpenGL or hardware rendering), the preview mode may not properly map the included texture. In these cases you will need to use higher quality rendering mode (similar to BestRender mode in ZBrush) for best results .

2. 3D/2D coordinates systems are not consistent across all 3D applications and you may need to adjust the mesh or texture for proper rendering (adjustments may include... Flipping one or more of the mesh axis, flipping the normals, and/or flipping the texture horizontally or vertically.

3. The UVTiles has been updated to offer better compatibility with the tested applications but some applications may require a different filter to be used for optimum result. if the above mesh is not rendered properly in your other 3D applications please email your test results to matthew@pixologic.com (matthew@pixologic.com) .

4. Texture antialiasing: Texture artifacts may be caused by the antialiasing mode (such as MipMapping) that is seleceted in the tested application . If you detect such artifacts, try a different antialiasing (sampling) mode (or reduce the antialiasing radius).


If you have successfully tested this mesh+texture in your other 3D application/s and have gotten results similar to the ZBrush-rendered images (above), please post your result and the required steps for proper rendering of the mesh, this information will become valuable to other members who are using these applications. (furthermore, these steps can later be ZScripted to allow for a customized one-click export-button that will execute these steps before exporting the mesh from ZBrush. )


If you have tried the above mesh but did not get the expected results, please email your your test results (with any other relevant information) to matthew@pixologic.com (matthew@pixologic.com)

Thanks,
-Pixolator

This test works with ElectricImage -
EIAS example
I have found that ZB AUVs works just fine inside EIAS.
This is the process I used:

- Downloaded the original obj and bmp files (PixZsphee50.OBJ and PixZsphee50.BMO).
- Opened the obj file in UVmapper, default settings, and exported the model from there (result: PixZsphee50_uvm.obj).
- Used O2F to get the new obj transported as a fact (PixZsphee50_uvm.fac)
- Imported the fact file to a new EIAS proyect, I did activate "use UV space" for the model and then added the bmp file at the difusse channel, also with default settings.
- Before rendering, I upped the sampling level for the model (nfo window, shading tab), to 2. Then I did the same in the render panel, antialias tab: default settings, but put the sampling level to 2.
- Hit Render and done.
http://206.145.80.239/zbc/attachment.php?attachmentid=9144

Gustavo Muñoz

Some of the settings Gus used are not needed, as mentioned above, turning off texture AA is a good idea.

Reuben

Igors
05-06-2006, 06:24 PM
Hi, Reuben
About AUV tiles, taken from zbrushcentral.comAhhaa, thanks for info, we know how it works, but didn't know a name - we never were too erudited :)

Ok, step by step

1. Don't overestimate a role of auto-alignment. Yes, it's unpleasant if a "bounded polygon" is missed/killed, but UV's are still correct, so all you need is:

- turn "normalize" off in Group Window
- use Calculator (win) to perform 1-2 dividing and copy/paste results into Texture Window

Not too much, sure :)

2. Just note that ZB posts UVs + map together, i.e. concrete UVs make sense only with concrete map and vice versa (unfortunately, we didn't catch this brilliant idea when we worked with uv mapping long time ago :sad: )

3. Don't rely too much on powerful of "adaptive" UV, there is no principal difference between adaptive and uniformed: adaptive makes less seams, but.. only if a concrete model allows (as always adaptive eats much more programmer's time)

4. We are familiar with the sampe you post. Sorry, Reuben, but IMO it's absolute not suitable to be a subject of testing/learning just cause diffuse texture is much more tolerant to seams compare to bump/displ texture. Math says that deivative (bump) is always much less stable than a function itself (diffuse). And math rules are always confirmed (no matter we like or nope,). This texture should be "well-seamed" for bump.

5. but put the sampling level to 2turning off texture AA is a good ideaOf course, artist can use any ways to achive results he needs. But what we talk about: a normal/regular render or about render "as it's good for ZB"? These things are much different.

We've no questions for Matusha from ZB cause we see he understands perfectly what we understand

Reuben5150
05-06-2006, 07:11 PM
Hi, Reuben
Ahhaa, thanks for info, we know how it works, but didn't know a name - we never were too erudited :)

Ok, step by step

1. Don't overestimate a role of auto-alignment. Yes, it's unpleasant if a "bounded polygon" is missed/killed, but UV's are still correct, so all you need is:

- turn "normalize" off in Group Window
- use Calculator (win) to perform 1-2 dividing and copy/paste results into Texture Window

Not too much, sure :)

But its not just the texture scale that's lost its also positioning, thats 2x more potential for "user error", i need to rule out any possibility of mis-alignment when doing these "tests", but ok, maybe i'll give it another go.

4. We are familiar with the sampe you post. Sorry, Reuben, but IMO it's absolute not suitable to be a subject of testing/learning just cause diffuse texture is much more tolerant to seams compare to bump/displ texture. Math says that deivative (bump) is always much less stable than a function itself (diffuse). And math rules are always confirmed (no matter we like or nope,). This texture should be "well-seamed" for bump.

yes i know :) , i just cut/paste everything on the page.

5. Of course, artist can use any ways to achive results he needs. But what we talk about: a normal/regular render or about render "as it's good for ZB"? These things are much different.

That is becoming more and more clear, ok thanks Igors.

Reuben

Reuben5150
05-06-2006, 08:14 PM
Well i seem to be having some success without even using windows calculator :D

Mapped with AUV tiles and its a diffuse map only, we'll see how it goes, but one thing i will say.. i've tried many times to map a texture to this model and failed, -"dazed and confused" yet again :argh:




http://www.btinternet.com/~reuben.flounders/wipimages/New_zb_test.jpg

Reuben

AVTPro
05-06-2006, 08:27 PM
I'm glad you guys are giving this your attention. Seem to have some really nice things happening. Looks good Rueben . I like your image. I still don't subscrible to AUV but I do hope you find a solutions. If you can shed some light on your settings please do. Thanks.

Let keep hammering til we breakthrough. GUVs. No seams.

http://i47.photobucket.com/albums/f190/AVTPro/Cubesolve.jpg

The project file
http://homepage.mac.com/avtpro5/.Public/AVT_ZB-EI-GUV.sit

How it was done.
Personal study on AUV vs. GUV
and How I rendered this with no seams.
These video recording with a lecture
90 mb
http://homepage.mac.com/avtpro5/.Public/AVT%20AUV_GUV.sit

Please veiw this in the spirit it was given.
Hope it helps.

To God be the Glory Enjoy!

AVTPro
05-06-2006, 08:41 PM
UNIFIED TILES...I remember when you did this Rueben. I had NO CLUE what that stuff was back then. I believe that would be another if not PERFECT solution. I haven't tried it yet tho.

I need some rest first.

AVTPro
05-06-2006, 08:49 PM
Alonzo, i would forget about the cube project, it will only complicate your test results because EI cannot auto-align textures to that model.

We have seen a good working example (the primitive-man-turtle-head:) this is nothing new though, now i think we need a new project, something simple like the cube using GUV tiles since this was how turtle-head was mapped, and then converted with obj2fac2.

As pointed out by Malcolm recently, we've all had some degree of success with EI+ZB, but the problem is inconsistent results, or like "sometimes it works sometimes it don't".

You need to try and reproduce what does work.

I might be able to help out a bit, but until there is means of an accurate model conversion on PC its poinless me providing projects IMO.

Reuben

Yes, I agree. It's going to be very difficult for you to continue if placement is a pelimenary problem. However I do finish your cube or my rendition of your cube. I truly admire your tenacity and your willingness to share. Malc has been a help also, and we have gone back and forth on many points. I agree with you both if it doesn't work consistently it's not a full solution. It's best to go with what works.

BTW, I will look into the UNIFIED UV...which is that? UVTiles. I tell you I really looked the worked you posted when I say this a year or so ago.

Reuben5150
05-06-2006, 09:27 PM
Yes, I agree. It's going to be very difficult for you to continue if placement is a pelimenary problem.

BTW, I will look into the UNIFIED UV...which is that? UVTiles. I tell you I really looked the worked you posted when I say this a year or so ago.

Yes placement is/was a problem, that is why i posted the image above.

I think i was talking about "UV tiles", i always had problems using it though, ZB hangs when generating a displacement map.

Ok, got some jobs to do, will post back if i have anything "interesting"

Igors
05-06-2006, 10:36 PM
Well i seem to be having some success without even using windows calculator :D

Mapped with AUV tiles and its a diffuse map only, we'll see how it goes, but one thing i will say.. i've tried many times to map a texture to this model and failed, -"dazed and confused" yet again :argh:
ReubenWell, let's hope for "Your Time is Gonna Come" :)

Reuben5150
05-07-2006, 01:43 AM
Because "I Can't Quit You Baby" so here's my progress :)

http://www.btinternet.com/~reuben.flounders/wipimages/New_zb_test1_1.jpg

First, the black areas on the forehead are my fault, not enough geometry in that area ;)

So what we have is a ZB model mapped with AUV tiles, i'm using a positive AND negative !!! displacement map and there's no "dead areas" or other oddity's, i've shocked myself.

Ok so there's not as much detail as i see in ZB, thats to be expected to some degree, but i'm working on improving this.

Alonzo, i suggest using the alpha proccessing tools in Zbrush, it has its own positive and negative curves which you can load, they are in the Zcurves folder.

Oh and btw, i only used the sculpting tools on this model, no "projection master" yet.

Reuben

Reuben5150
05-07-2006, 02:22 AM
The project file
http://homepage.mac.com/avtpro5/.Public/AVT_ZB-EI-GUV.sit

How it was done.
Personal study on AUV vs. GUV
and How I rendered this with no seams.
These video recording with a lecture
90 mb
http://homepage.mac.com/avtpro5/.Public/AVT%20AUV_GUV.sit

Please veiw this in the spirit it was given.
Hope it helps.

To God be the Glory Enjoy!


I can't watch the movie, says "error this is not a movie file" :hmm:

R

AVTPro
05-07-2006, 07:25 AM
I can't watch the movie, says "error this is not a movie file" :hmm:

R


Did the stuffit file decompress? It's two Sorenson 3 video codecs and a read me. Maybe it's one of the PC things :)

I can compress it for you cinepak? I really want you to see it. I successful used one of the automapping features GUV in ZBrush with EIAS...

Reuben5150
05-07-2006, 03:48 PM
Yeah i decompressed the file but they were bad, always have prob's with stuffit.

Latest test -

http://www.btinternet.com/~reuben.flounders/wipimages/ZBlizardhead_1.jpg

http://www.btinternet.com/~reuben.flounders/wipimages/ZB-lizardhead_2.jpg

AUV tiles again, What can i say :rolleyes:

Reuben5150
05-07-2006, 06:46 PM
I thought there was something wrong with the above images, the displacement is inverted, example -

Positive map setting - Bump factor : 0.2
Displacement : 0.25

Negative map - Bump factor : -0.2
Displacement : -0.25

To achieve correct displacement results i have to apply the minus value to the positive map !!!.

I am collecting a project to post on the beta server, ok heres a better result -
http://www.btinternet.com/~reuben.flounders/wipimages/ZBlizardhead_3.jpg


there is an "oddity" on the nose area, that was there in Zbrush, apart from that i'm happy this the result :thumbsup:

Reuben

Reuben5150
05-07-2006, 11:47 PM
I keep pushing up the bump/displace values, holding together very well, cant seem to break it, excellent !


http://affinity3d.com/gallery2/main.php?g2_view=core.ShowItem&g2_itemId=306

http://affinity3d.com/gallery2/main.php?g2_view=core.ShowItem&g2_itemId=309

http://affinity3d.com/gallery2/main.php?g2_view=core.ShowItem&g2_itemId=314

Time for a nap :wavey:

AVTPro
05-08-2006, 03:10 AM
Yeah i decompressed the file but they were bad, always have prob's with stuffit.

Latest test -
AUV tiles again, What can i say :rolleyes:


Nice stuff. I would like to know your setup with AUV tiles. I don't seem to have any problems with GUVs. So I think we essentially wrestled the ZBrush Monster down to the ground.

Anybody else have problems with the movie files? Some feedback would be nice.

Igors
05-08-2006, 10:01 AM
Hi, Reuben, Alonzo
I keep pushing up the bump/displace values, holding together very well, cant seem to break it, excellent !


http://affinity3d.com/gallery2/main.php?g2_view=core.ShowItem&g2_itemId=306

http://affinity3d.com/gallery2/main.php?g2_view=core.ShowItem&g2_itemId=309

http://affinity3d.com/gallery2/main.php?g2_view=core.ShowItem&g2_itemId=314

Hmmm... as we remember, a same value for bump and displace is what EI doc recommends :) Your links are not available yet, but in any case please upload prjs (zip is better for PC and fully understandable on Mac)

Also tell us what Camera vers was used and on which platform. Alonzo, for your AVT_ZB-EI-GUV.sit we've got significantly different results than you showed. Vers info please

WmH
05-08-2006, 01:52 PM
Hi, Reuben, Alonzo
Hmmm... as we remember, a same value for bump and displace is what EI doc recommends :) Your links are not available yet, but in any case please upload prjs (zip is better for PC and fully understandable on Mac)

Also tell us what Camera vers was used and on which platform. Alonzo, for your AVT_ZB-EI-GUV.sit we've got significantly different results than you showed. Vers info please

A lot of people using OS X don't even realize zip compression is quickly and easily available (in the OS) so they use .sit because they are used to using the drop stuff utility (from the old MacOS days)

Select a file, files, or a folder then select "Create Archive" from the File menu (in finder). A new file will be created with the extension .zip, this is a zip archive of the selected files/folders.
That's it...

Stuffit archives are a problem for PC users (and sit hasn't been really great format for OS X users either) so always use zip archives when posting files for general distribution.
(.dmg (disc image) is acceptable/preferred for OS X only recipient's)

Reuben5150
05-08-2006, 03:06 PM
Hi, Reuben, Alonzo
Hmmm... as we remember, a same value for bump and displace is what EI doc recommends :) Your links are not available yet, but in any case please upload prjs (zip is better for PC and fully understandable on Mac)

Also tell us what Camera vers was used and on which platform. Alonzo, for your AVT_ZB-EI-GUV.sit we've got significantly different results than you showed. Vers info please

I like to break the rules occasionly :), unavailable links suggest server problem :banghead:

Ok, i uploaded 2 projects to - windows bug projects/ ZB inverse displacement.zip
1 correct result, 1 incorect.

I'm not saying this is a bug because i could have simply got the 2 map names mixed up, but i'm sure i did not, so results are strange to say the least.

I am running the latest beta animator/camera on windows.

Reuben

Reuben5150
05-08-2006, 04:14 PM
Hi, Reuben, Alonzo

For normalized UV's it's not a big problem to calculate scales manually. Hmm.. maybe it would be interested to re-check a sword model you rendered?
[/left]
[/center]

I've just rebuilt the zSword displacement test from the source files.. and i'm getting excellent results !!!, but, again the displacement is inverted, i was not wrong cause this project only uses positive displacement :wise:

It would seem that some undocumented changes have been made to the displacement system, if that's the case (even inverted ;) thanks very much, because i'm now back on track with zbrush and EI.

I will post the results of the zSword test and upload another project to the beta site, for any one who's "watching" here's a link to the zSword test -

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

BBL :)

AVTPro
05-08-2006, 04:17 PM
I like to break the rules occasionly :), unavailable links suggest server problem :banghead:

Ok, i uploaded 2 projects to - windows bug projects/ ZB inverse displacement.zip
1 correct result, 1 incorect.

I'm not saying this is a bug because i could have simply got the 2 map names mixed up, but i'm sure i did not, so results are strange to say the least.

I am running the latest beta animator/camera on windows.

Reuben

I had that problem once with the moon I posted too Rueben. I generated an inverted map from ZBrush. I could visually distinguish that it was inverted so swithed the polarity values (+/-) to (-/+) and it worked fine.


I used very 6.5. You could see the splash screen. So the videos worked?
If it helps I will .zip them.

Reuben5150
05-08-2006, 04:22 PM
Hi Alonzo, no i can't watch the movies, you'll have to zip them :shrug:

Ok , back soon, i got more stuff :)

AVTPro
05-08-2006, 04:24 PM
I've just rebuilt the zSword displacement test from the source files.. and i'm getting excellent results !!!, but, again the displacement is inverted, i was not wrong cause this project only uses positive displacement :wise:

It would seem that some undocumented changes have been made to the displacement system, if that's the case (even inverted ;) thanks very much, because i'm now back on track with zbrush and EI.

I will post the results of the zSword test and upload another project to the beta site, for any one who's "watching" here's a link to the zSword test -

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

BBL :)
I'm glad everything is working now.


Can you post a link to the UVtile creature "page", the direct link to DL creature? It's not working for me.

Thanks Rueben.
BTW, I gave you much credit in the videos. FWIW.

Reuben5150
05-08-2006, 04:43 PM
Here's the page -

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

:)

Reuben5150
05-08-2006, 05:22 PM
zSword test results -


http://www.btinternet.com/~reuben.flounders/wipimages/zSword_1.jpg

http://www.btinternet.com/~reuben.flounders/wipimages/zSword_2.jpg
http://www.btinternet.com/~reuben.flounders/wipimages/zSword_3.jpg
http://www.btinternet.com/~reuben.flounders/wipimages/zSword_4.jpg

Pretty close to the original, good result :)

Reuben

AVTPro
05-08-2006, 06:22 PM
And here's the zip.

http://homepage.mac.com/avtpro5/.Public/AVT%20AUV_GUV.zip

So you are using AUVs? This looks great.

each video is 20 mins.

I didn't have success with AUV but GUV worked fine. Maybe you can crit it, if you see where I'm missing it.

I did the videos after being up all nite so forgive any incorrect terminology.

Igors
05-08-2006, 07:47 PM
Hi, Reuben
Ok, i uploaded 2 projects to - windows bug projects/ ZB inverse displacement.zip 1 correct result, 1 incorect.In your prj we see 2 maps, and, as we understood, both are far away from original. The result is named as "correct". Hmmm... it's correctness is absolute not obvious for us :) How about to upload just ZB original map (and ZB original image)?

Reuben5150
05-08-2006, 08:39 PM
Hi Igors and Alonzo,

I will post another project with images that shows the problem more clearly.

Alonzo, thanks for posting the movies and yes the zSword project was using AUV's

Here are the settings you need to use for a clean render with AUV tiles -

In the texture editor under the filter tab, turn off Anti-alias, then under object info/shading set the sampling level to 2x2, also do this for global sampling in renders settings under Anti-aliasing - thats it :)

I understand what you say about GUV's in the movie, but as far as i can remember, all the "flat spots" or "dead areas" have happened when GUV's were used, like Turtle head :)(might be wrong though), anyway, the few projects i've done recently all used AUV's and i've not seen any of those prob's.

I think Malcolm would be interested in your Obj2Fac2 settings ;)

Reuben5150
05-08-2006, 09:14 PM
New project posted to - Windows bug projects/zSword inverse disp.zip

Reuben

Igors
05-08-2006, 10:51 PM
Hi, Reuben
New project posted to - Windows bug projects/zSword inverse disp.zipThx, we've seen it. We guess the cause of reversed direction is reversed polygons normals, that's often called as "bad winding order". We couldn't check it exactly, no luck with EI re-import - but that's another story. And, Reuben, in further tests please post original image only, all this "pos", "neg", "2" etc. confuse us very much :scream: BTW: displacement direction is NOT a surface normal (in EI and other apps as well)

Reuben5150
05-08-2006, 11:00 PM
Hi, Reuben
Thx, we've seen it. We guess the cause of reversed direction is reversed polygons normals, that's often called as "bad winding order". We couldn't check it exactly, no luck with EI re-import - but that's another story. And, Reuben, in further tests please post original image only, all this "pos", "neg", "2" etc. confuse us very much :scream: BTW: displacement direction is NOT a surface normal (in EI and other apps as well)

Ok, thanks again for the info, confusion not intended :blush: :) :thumbsup:

AVTPro
05-09-2006, 03:23 AM
I remember why the displacement maps are backwards sometimes. I believe it's photoshop problem, not a EI or ZB problem. If you are are using curves that Lolo created to separate the maps, I believe the curves were generated on a grayscale image. So if you load the curves on a RGB, it's gets wacky.

AVTPro
05-09-2006, 03:30 AM
Hi Igors and Alonzo,

I will post another project with images that shows the problem more clearly.

Alonzo, thanks for posting the movies and yes the zSword project was using AUV's

Here are the settings you need to use for a clean render with AUV tiles -

In the texture editor under the filter tab, turn off Anti-alias, then under object info/shading set the sampling level to 2x2, also do this for global sampling in renders settings under Anti-aliasing - thats it :)

I understand what you say about GUV's in the movie, but as far as i can remember, all the "flat spots" or "dead areas" have happened when GUV's were used, like Turtle head :)(might be wrong though), anyway, the few projects i've done recently all used AUV's and i've not seen any of those prob's.

I think Malcolm would be interested in your Obj2Fac2 settings ;)

Thanks for the feedback Rueben. I had to take the videos down because Apple (.Mac) said I was using too much bandwidth.

I'm pretty sure the flat was because I changed the levels of the displacement maps in Photoshop. I know I upped the constrast inorder to get stronger displacements but I probably should do that with incremental test of Bump/displ. setting directly in EI.

I will check and eye tho and see if I'm in error.

Also, I just did sword render in GUV and it's gorgeous. However, If AUV is working, (and by your tests, they are) I need to get that under control as well.

AVTPro
05-09-2006, 04:06 AM
Not sure what file came from where, but I render the one that said GUV...No Beef here.

BTW, I did talk to Matt. There hasn't been any changes or upgrades to Camera in terms of ZBrush. The door has just been unlocked.

http://i47.photobucket.com/albums/f190/AVTPro/swordGUV.jpg

AVTPro
05-09-2006, 04:52 AM
OK. now that we have texture placement and seam issues on a short leash.

I am beginning to see where degrading the quality of the maps from 16 bit to 8 and the resolution of subpixels would be a concern.

http://i47.photobucket.com/albums/f190/AVTPro/SwordsMan.jpg

Whoops miss the part about Malc.

It's very clean straight settings from Lolo's tute.

Join groups and vertice. Recalc normals and reserve.

AVTPro
05-09-2006, 06:15 AM
Last but definitely not least.

AUV as in Adaptive. Not Auto. I'm on the same page now. This is my first AUV render that works. It looks good and another option with benefits of texture resolution based on polygon size. So it's Zbrush thing that promises no stretching. I think it's good if you use Zapplink for Photoshop editing of the texture, then touch up whatever projection smearing it makes in Zbrush interface. But at least, I have finally warmed up to it :)

I'll do more testing with this as well but with my own modeling.
http://i47.photobucket.com/albums/f190/AVTPro/Project_11.jpg

Reuben5150
05-10-2006, 03:33 PM
I said was going to look at this after I did my test. I saw your original beta test report.
I couldn't figure out why you were having problems with placement, especially with UVs. This is what I found.



http://i47.photobucket.com/albums/f190/AVTPro/RuebensCube.jpg


No problem with placement or seams.




I didn't separate the maps in PS, I think that is where the banding is coming from,but it's not seams.




If you have a model you need converted let me know Rueben's let me know.

Alonzo, one question, is this the first time you have seen this effect when working with EI+ZB ?

Reuben

Reuben5150
05-11-2006, 04:13 PM
Look what i found -

http://www.btinternet.com/~reuben.flounders/wipimages/ZB-banding.jpg

Its started happening with every new project i create, i've got no idea why its happening, i'm doing nothing different, don't get it..

As mentioned, i increased the bump and displacement for a previous "working" project to a really high level as a stress test and it displaced perfectly, the project below is "rock solid" -

http://www.btinternet.com/~reuben.flounders/wipimages/ZB-lizardhead_5.jpg

ahhh ok i'll upload another project today...

Reuben

Reuben5150
05-11-2006, 10:01 PM
Igors, i've upped another project to windows bugs projects/ZB Banding.zip

Your time is appreciated.

Reuben

Igors
05-11-2006, 10:02 PM
Hi, ReubenLook what i foundSorry, but for us it's absolute not clear WHAT (Communication Breakdown). Where is the prj? Original map? Settings? IMO it's better to learn a single prj in all details instead of running thru numerous lizards. Up to now we cannot support the discussion cause we see no facts but assumptions only

Reuben5150
05-11-2006, 10:42 PM
The problem is "visually"clear as shown in this image and the project has been posted to the specified place.

http://www.btinternet.com/~reuben.flounders/wipimages/ZB-banding.jpg

Whether its discussed here or not is of no importance to me, what is important IMO is that these inconsistencies with displacement are sorted out, this is the very reason i gave up with these "tests" in the first place.

Alonzo stumbled upon this problem with the "cube" project as shown in his image.

If its not a problem with EIAS then someone say so, cause i am unconvinced that EIAS is not the problem.

Now AFAIK its up to EI technology and its sub-contractors, i've done enough and had enough.

adios amigo's

AVTPro
05-12-2006, 09:02 AM
The problem is "visually"clear as shown in this image and the project has been posted to the specified place.

http://www.btinternet.com/~reuben.flounders/wipimages/ZB-banding.jpg (http://www.btinternet.com/%7Ereuben.flounders/wipimages/ZB-banding.jpg)

Whether its discussed here or not is of no importance to me, what is important IMO is that these inconsistencies with displacement are sorted out, this is the very reason i gave up with these "tests" in the first place.

Alonzo stumbled upon this problem with the "cube" project as shown in his image.

If its not a problem with EIAS then someone say so, cause i am unconvinced that EIAS is not the problem.

Now AFAIK its up to EI technology and its sub-contractors, i've done enough and had enough.

adios amigo's

Hey Rueben...Not exactly where to answer this because I just described the problem here in this forum.

Yes, it's the first time I got banding. I believe it is as I just mentioned with low fidelity image in directly generating an 8 bit from ADE.

It's banding, due to lack of gradiation in the grayscale image map. So, 128 levels of gray in 8 bit isn't enough to describe the smoothness of image as a 16 bit or 32 would.

Then, I believe the problem maybe be compounded by lack of AA or Blur.
I can't be sure of this, haven't really been infront of the computer for a couple days. (not much :)


Hey Rueben Sorry been having a couple of days fun in the sun... to feel human again.

Sorry I couldn't get back to this. This is why...and oddly enough, keep photoshop in the mix (process) would be still be a good thing. So if you keep the 16 bits as long as possible it's good. but if you go 8 bit, with no blur or AA or room for EI to smooth out the lack of data in the image, I believe it will band.

In the old printing world, 8 bits were never enough to describe a some graduated tone. Some of the other setting need to be available if you use them...like Blur. Or some other compensation in the render to smooth the image.

At least that is what I posted last. "The need for 16 bit will eventually become aparent."

When I get a moment I will instigate your ADE script.

You did a lot of great work...don't give up.

AVTPro
05-12-2006, 09:04 AM
The problem is "visually"clear as shown in this image and the project has been posted to the specified place.

http://www.btinternet.com/~reuben.flounders/wipimages/ZB-banding.jpg (http://www.btinternet.com/%7Ereuben.flounders/wipimages/ZB-banding.jpg)

Whether its discussed here or not is of no importance to me, what is important IMO is that these inconsistencies with displacement are sorted out, this is the very reason i gave up with these "tests" in the first place.

Alonzo stumbled upon this problem with the "cube" project as shown in his image.

If its not a problem with EIAS then someone say so, cause i am unconvinced that EIAS is not the problem.

Now AFAIK its up to EI technology and its sub-contractors, i've done enough and had enough.

adios amigo's

Hey Rueben...Not exactly where to answer this because I just described the problem here in this forum.

Yes, it's the first time I got banding. I believe it is as I just mentioned with low fidelity image in directly generating an 8 bit from ADE.

It's banding, due to lack of gradiation in the grayscale image map. So, 128 levels of gray in 8 bit isn't enough to describe the smoothness of image as a 16 bit or 32 would.

Then, I believe the problem maybe be compounded by lack of AA or Blur.
I can't be sure of this, haven't really been infront of the computer for a couple days. (not much :)


Hey Rueben Sorry been having a couple of days fun in the sun... to feel human again.

Sorry I couldn't get back to this. This is why...and oddly enough, keep photoshop in the mix (process) would be still be a good thing. So if you keep the 16 bits as long as possible it's good. but if you go 8 bit, with no blur or AA or room for EI to smooth out the lack of data in the image, I believe it will band.

In the old printing world, 8 bits were never enough to describe a some graduated tone. Some of the other setting need to be available if you use them...like Blur. Or some other compensation in the render to smooth the image.

At least that is what I posted last. "The need for 16 bit will eventually become apparent." I know you also want super crispness but without micropolys...it's going to be only so sharp on detail. Without 16 bit or micropolys, efforts to sharpen the image map with big out flaws. I feel 8 bits with ZBrush is doable.

When I get a moment I will instigate your ADE script.

You did a lot of great work...don't give up.

Igors
05-12-2006, 10:55 AM
Hi, ReubenIgors, i've upped another project to windows bugs projects/ZB Banding.zipThx, clear now. Yes, with such textures (like in ZB Banding) the "moire" is what should be rendered. In black areas RGB values (0..255) are like a lot of zeros with seldom 1-2 here and there. That's enough only to get a moire we see. Your maps are sorta "terrains" - micro and macro are in one, that's not for 8-bits.

About positive/negative (2 maps).. we don't understand what do you want to achieve. It would be clear if you've 2 original maps, but without it.. we've no idea, please explain.

Reuben5150
05-12-2006, 03:34 PM
Hi, ReubenThx, clear now. Yes, with such textures (like in ZB Banding) the "moire" is what should be rendered. In black areas RGB values (0..255) are like a lot of zeros with seldom 1-2 here and there. That's enough only to get a moire we see. Your maps are sorta "terrains" - micro and macro are in one, that's not for 8-bits.

About positive/negative (2 maps).. we don't understand what do you want to achieve. It would be clear if you've 2 original maps, but without it.. we've no idea, please explain.

Hi Igors, forgive my "tone" earlier (had a hard day).

Ok it would seem that in areas with no or little displacement/bump info this banding happens, yes ? this is the only difference i can see between "ZB banding" and "lizard head" projects, lizard head is almost fully covered with a bump/disp.

Maybe this is not such a problem.

The provided maps were the original exported ones, as we know Zbrush uses a 50% gray mid-point, these maps were generated with the ADE displacement exporter.

The positive/negative maps provide a solution for "standard" renderers where by 100% black = no displacement, the positive map contains the outward displacement info, negative = inwards, this has worked very well for me with AUV tiles without any of the "lines" around the transition between the 2 maps (like you seem to get with GUV).

thanks

Igors
05-12-2006, 06:24 PM
Hi, Reuben
Ok it would seem that in areas with no or little displacement/bump info this banding happens, yes ? this is the only difference i can see between "ZB banding" and "lizard head" projects, lizard head is almost fully covered with a bump/disp.The calculation of perturbed surface normals (bump/displ) is same anywhere, it's based on math from times of 17-18 century. The calculation is very simple (in principle) and (to avoid math/geometry specifics) can be formulated as: perturbed normal is a texture's difference (gradient), not its absolute values. So, just see your textures: are there nice greyscale transitions/gradients? If yes, than a good bump/displ is guaranteed. Note that gradient's smoothness is much, much more important than gradient's amplitude/range. A map can be very dark or very bright overview - it's not a big deal, the importance is only how many half-tones you have. If you see almost no transitions (as in ZB banding), so you've no chances to see rational bump/displ in these areas. It's same like if you increase dramatically an amplitude of dark texture areas in PS: yes, you've got more white, but.. very rough, no gradient, no data and any amplifying can't help.
The provided maps were the original exported ones, as we know Zbrush uses a 50% gray mid-point, these maps were generated with the ADE displacement exporter.

The positive/negative maps provide a solution for "standard" renderers where by 100% black = no displacement, the positive map contains the outward displacement info, negative = inwards, this has worked very well for me with AUV tiles without any of the "lines" around the transition between the 2 maps (like you seem to get with GUV).First off, there is an popular contradiction between "artist's language" and "technical language". Artists: "I'm not interested in bump maps", "Don't worry about surface normals" etc. For artist it's fully obvious (and self-clear) that if a surface is pushed inside/outside, then we must see it visually (darkness in pits areas for example). But technically "vertices positions" and "surface normals" are handled individually, absolute not automatically (typically 1% of work for "positions" and 99% for "normals"). If surface normals remain unmodified, you can't see pits/hills but only a strange "ice" (just specify a much less bump than displ to check). Any modification of geometry (displacement, deformation - anything) should be "confirmed" by surface normals modifying, otherwise result = absurd.

So, all these 0%, 50%. 100% (or any %) change nothing in surface normals and result's "mimics" (very convenient artistic term :)) remains absolute same. You just expand/shrink a model, but nothing more. Of course, it's affair of artist how many maps should be used. Just it's more rational/practical to start from a single map, be sure it gives a good gradient, and then (if needed) switch to 2 (or more) maps.

AVTPro
05-12-2006, 06:37 PM
Hi Igors, forgive my "tone" earlier (had a hard day).

Ok it would seem that in areas with no or little displacement/bump info this banding happens, yes ? this is the only difference i can see between "ZB banding" and "lizard head" projects, lizard head is almost fully covered with a bump/disp.

Maybe this is not such a problem.

The provided maps were the original exported ones, as we know Zbrush uses a 50% gray mid-point, these maps were generated with the ADE displacement exporter.

The positive/negative maps provide a solution for "standard" renderers where by 100% black = no displacement, the positive map contains the outward displacement info, negative = inwards, this has worked very well for me with AUV tiles without any of the "lines" around the transition between the 2 maps (like you seem to get with GUV).

thanks

Yes, Displacement is cool but there's some drawback with settings that directly generate 8 bit. I still export 16 bit. I haven't tested it enough tho, so maybe there's something that works. But I still hold on to the 16 to 8 bit conversions as long as I can during the process.

If this is directly related to the ADE posting in PostForum. I would make a correction or addendum.

AVTPro
05-12-2006, 06:56 PM
Hi, ReubenThe calculation of perturbed surface normals (bump/displ) is same anywhere, it's based on math from times of 17-18 century. The calculation is very simple (in principle) and (to avoid math/geometry specifics) can be formulated as: perturbed normal is a texture's difference (gradient), not its absolute values. So, just see your textures: are there nice greyscale transitions/gradients? If yes, than a good bump/displ is guaranteed. Note that gradient's smoothness is much, much more important than gradient's amplitude/range. A map can be very dark or very bright overview - it's not a big deal, the importance is only how many half-tones you have. If you see almost no transitions (as in ZB banding), so you've no chances to see rational bump/displ in these areas. It's same like if you increase dramatically an amplitude of dark texture areas in PS: yes, you've got more white, but.. very rough, no gradient, no data and any amplifying can't help.

Very good Igors. This is why I got some flat areas when expanding gradiation to a broader gamut. Because though range doesn't matter gamut does. So I learned better ways to expand the range without losing important parts of the gamut. This is why photoshop is still good in the process, tho' a bit more time consuming. As an artist I would like to reduce that time. I still haven't used curves in Zbrush directly yet.


First off, there is an popular contradiction between "artist's language" and "technical language". Artists: "I'm not interested in bump maps", "Don't worry about surface normals" etc. For artist it's fully obvious (and self-clear) that if a surface is pushed inside/outside, then we must see it visually (darkness in pits areas for example). But technically "vertices positions" and "surface normals" are handled individually, absolute not automatically (typically 1% of work for "positions" and 99% for "normals"). If surface normals remain unmodified, you can't see pits/hills but only a strange "ice" (just specify a much less bump than displ to check). Any modification of geometry (displacement, deformation - anything) should be "confirmed" by surface normals modifying, otherwise result = absurd.

Again I agree Igors, bump is very importand to a good displacement and the two are co-dependent in most cases. ADE is good because it can export a full active sets Bump, Disp, and Normal. I aslso think there is another type, called caveat. Depending on the project you may want to be very picky of each map individually and lots of time perfecting each or just need a fast export pipeline. At one point I did think using more maps could smooth the look of surface but I can't substanciate that. However, tho you could smooth banding with a blur in PS, I would perfer to get the smoothest range then leave blur in EI render. Don't want to get into all the funky insufficient tricks to fix a stair-stepping map.


So, all these 0%, 50%. 100% (or any %) change nothing in surface normals and result's "mimics" (very convenient artistic term :)) remains absolute same. You just expand/shrink a model, but nothing more. Of course, it's affair of artist how many maps should be used. Just it's more rational/practical to start from a single map, be sure it gives a good gradient, and then (if needed) switch to 2 (or more) maps.

Yes, start with one map with high depth, separete or correct gradient range, then split, then reduce to 8 bit. So making all edit before simplifying. I would rather have a small range then up the levels to a more dynamic range in PS. Then only cut the lower value because "artistically" darkers areas are less distinguishable.

One question, Igors. If I shift the nuetral area and move the 50% nuetral to 0, what happens to darker areas? It goes to negative? And I only have to export two maps with no separation? Interesting thought?

Reuben5150
05-12-2006, 07:15 PM
Hi, ReubenThe calculation of perturbed surface normals (bump/displ) is same anywhere, it's based on math from times of 17-18 century. The calculation is very simple (in principle) and (to avoid math/geometry specifics) can be formulated as: perturbed normal is a texture's difference (gradient), not its absolute values. So, just see your textures: are there nice greyscale transitions/gradients? If yes, than a good bump/displ is guaranteed. Note that gradient's smoothness is much, much more important than gradient's amplitude/range. A map can be very dark or very bright overview - it's not a big deal, the importance is only how many half-tones you have. If you see almost no transitions (as in ZB banding), so you've no chances to see rational bump/displ in these areas. It's same like if you increase dramatically an amplitude of dark texture areas in PS: yes, you've got more white, but.. very rough, no gradient, no data and any amplifying can't help.


Ok, now i understand, thanks, i wasn't visually inspecting the maps, just expected it to work:D

Reuben5150
05-12-2006, 07:25 PM
If this is directly related to the ADE posting in PostForum. I would make a correction or addendum.

No, there is nothing more that can be done with that exporter to improve the results, it has a "smooth" setting which seems to apply some amount of blur, but i could not see any difference in the rendered output.

BTW, i've looked at a lot of the displacement tests on zbrushcentral.com and a lot of the other renderers produce similar banding effects when 8bit maps are used, obviously there is only one solution to this :rolleyes:

Reuben5150
05-12-2006, 07:29 PM
Yes, Displacement is cool but there's some drawback with settings that directly generate 8 bit. I still export 16 bit. I haven't tested it enough tho, so maybe there's something that works. But I still hold on to the 16 to 8 bit conversions as long as I can during the process.
.

I will try converting 16>8 bits in PS but i can't see there being any difference.

Reuben5150
05-12-2006, 07:44 PM
I will try converting 16>8 bits in PS but i can't see there being any difference.

Alonzo, you are right !, PS conversion to 8 bits gives much better results !, but sorry i'm not going to re-do the ADE expoter codes, no i think Pixolator shoud be made aware of this, the whole point of the ADE is to improve workflow, i'll make some comparison shots and post em to ZBC.

Reuben5150
05-12-2006, 10:36 PM
Actually PS conversion versus ADE export hmm i can't say one is better than the other, with ps there is less banding but also less detail and more grain, ok..

Time for time out ! :)

AVTPro
05-12-2006, 11:25 PM
Alonzo, you are right !, PS conversion to 8 bits gives much better results !, but sorry i'm not going to re-do the ADE expoter codes, no i think Pixolator shoud be made aware of this, the whole point of the ADE is to improve workflow, i'll make some comparison shots and post em to ZBC.

Great youre finding what works and what's not as good. So, just trying to be objective (as I usually am :)

True or False?

The ADE you posted work well with desired results?
The ADE settings on PF produce banding?
ADE with 16 bit produced desirable results?
Photoshop conversion from 16 to 8 workflow produce desire results?
Did blur in EI help any of your result or with or without AA?

Just something to think about. ADE 8 bit exports may work with some packages, but not EI.

Thanks for sharing your progress Rueben.

Igors
05-13-2006, 09:44 AM
Hi, AlonzoOne question, Igors. If I shift the nuetral area and move the 50% nuetral to 0, what happens to darker areas? It goes to negative? And I only have to export two maps with no separation? Interesting thought?Well, it requires to know well what is a shift, neutral etc. etc. It's easy to confuse all this. Let us give you a simple formulas that are true for any operations:

displace_height = greyscale(x, y) * disp_factor
normal_perturb = (greyscale(x + dx, y + dy) - greyscale(x, y)) * bump_factor

where:

- x, y - 2D image (pixels) coordinates

- dx, dy - delta step in pixels (defined by texture's samples, AA, blur). For simplicity you can think dx = dy = 1

- disp_factor, bump_factor - interface values (Texture Window)

Displacement is applied to vertices only, normals' recalculation - to each rendered point.

Reuben5150
05-16-2006, 11:37 PM
Great youre finding what works and what's not as good. So, just trying to be objective (as I usually am :)

True or False?

1 The ADE you posted work well with desired results?
2 The ADE settings on PF produce banding?
3 ADE with 16 bit produced desirable results?
4 Photoshop conversion from 16 to 8 workflow produce desire results?
5 Did blur in EI help any of your result or with or without AA?

6 Just something to think about. ADE 8 bit exports may work with some packages, but not EI.

Thanks for sharing your progress Rueben.

1- True (within the limitations of 8bit)
2- In some cases, it is project dependent.
3- a photoshop conversion to 8bit is less accurate IMO, there is less detail but can also reduce the banding effect (if present) in final rendering.
4 read "3"
5 all already stated, blur cannot be use here, actualy its ok using default 1.0 but go past that and the seems will show up.

6 The ADE settings i provided are fine for EI, do i need to prove it ? :wise:

I would stay away from Major/minor though, this seems like a "theory" feature, like "in theory it does this", in practice not so good.

Reuben

AVTPro
05-17-2006, 12:59 AM
Hey Rueben, I haven't been doing much Zbrushing this week. Trying to clean up my drives. Thanks for getting back.

No, you don't have to prove it to me. I take your word for it. If I didn't "believe" you, I would just test it for myself. LOL. I would never suggest otherwise.

AUV/GUV is really not an issue for me. I don't plan on using it routinely since UVGroups takes seams/gaps or mis-renders completely out of the equation. Gaps in manual UV editing are non-existent. I'm simply not having it. That's why I have several succussful texture paints. I'm not saying other methods doesn't work. Remember, I'm the one who says " User error, not program error".

As I have said many times, I go with what I know works. I subscribe to my own UVs. The small amount of time it takes to do UVs, is worth the success to me. I will be doing more UVGroups renders soon enough.

This study we have been doing, I believe benefits the community, and I will do more but I never planned to use AUV/GUV in my general workflow. Eventhough, I believe AUV/GUV is workable, and does work. Even if AUVs and GUV were 120% reliable, I would still learn to use manual UVs because my goals are towards current studio workflows and not just the newest cool specialty thing. Manual UVs is basic stuff. Nothing special, but works. I'm glad I know it.


Since you are an Zbrush afficianado like me, I recommend you take a look at Scott Mills DVD just for the sake of it or love of it as I did with AUVs and GUV. (to know all I can about each process). You would see how it is nearly impossible to misfire with manual UVs if you know how to blend them and make them seamless. Just a suggestion.

http://web.mac.com/avtpro5/iWeb/Site/Blog/E681C9B2-9632-11DA-A009-0030657CE1C0.html

Good Luck and keep up the great work.

AVTPro
05-17-2006, 01:11 AM
Hi, AlonzoWell, it requires to know well what is a shift, neutral etc. etc. It's easy to confuse all this. Let us give you a simple formulas that are true for any operations:

displace_height = greyscale(x, y) * disp_factor
normal_perturb = (greyscale(x + dx, y + dy) - greyscale(x, y)) * bump_factor

where:

- x, y - 2D image (pixels) coordinates

- dx, dy - delta step in pixels (defined by texture's samples, AA, blur). For simplicity you can think dx = dy = 1

- disp_factor, bump_factor - interface values (Texture Window)

Displacement is applied to vertices only, normals' recalculation - to each rendered point.

Thanks Igors. That was absolutely not help. LOL. :)

Do you speak Artisanese instead of Programmar?

MagicEgger
05-19-2006, 10:57 PM
Hey fellas,

Cineon files, HDRI, store more levels of whites and blacks..
and we can read in EIAS...
to make a good .hdri displacement, you probably need to mix 3 exposures of maps.
what happens if we use converted .hdri grayscale files to .img
Probably we will have a better displacement render, right?

Tomas

AVTPro
05-21-2006, 06:47 AM
Wow! Thanks Tomas. You Rock. Going to have to look into that. I may need it, now that I'm begining to warm up to Zbrush.

http://i47.photobucket.com/albums/f190/AVTPro/ZBAVT.jpg

AVTPro
05-21-2006, 06:49 AM
Finally did some edge loops and quad in Maya.

http://i47.photobucket.com/albums/f190/AVTPro/BaseHead.jpg

AVTPro
05-21-2006, 06:52 AM
I'm going to have to redo these movies but that are a start. AUV does work if you use 2x2 sampling as well. It's iffy those

http://s47.photobucket.com/albums/f190/AVTPro/?action=view&current=2-AVT-GUV.flv

http://s47.photobucket.com/albums/f190/AVTPro/?action=view&current=1-AVT-AUV.flv


http://i47.photobucket.com/albums/f190/AVTPro/Quad_edges.jpg

AVTPro
05-26-2006, 05:57 AM
New Character

Cupitron.


I used Zbrush to polish it. No mapping yet.

http://i47.photobucket.com/albums/f190/AVTPro/sideshot.jpg

AVTPro
05-26-2006, 07:28 AM
I am going to move to the body. Special Thanks to Marissa Ellen Threet for being the cutie cutie baby model. She's almost 14 years old now. June 18th Happy B-Day Boonie

http://i47.photobucket.com/albums/f190/AVTPro/Cupitron.jpg

MagicEgger
05-30-2006, 10:23 PM
Hey,

I liked a lot you new model, your daughter, right?

Thankssss

Tomas

AVTPro
05-31-2006, 03:43 AM
Hey Tomas! thanks. Yes, my one and only Sunshine! :)

Except this is suppose to be a boy..but at that age...guess it don't matter. ahah.

Anyway, shortly I should be ready do to another video tute on ZB in EI. I have sort of lightened up on AUVs.

Also, I want to do an XP script for a multiple blend target in EI. Haven't touched XP in a very long time. I should be starting soon. First I have to finish modeling the head in Maya, then I figure I should to the morph test from EIM. It's still good at morphs, but I don't model in it anymore.

This is just WIP, I'm not fighting wmps. I don't have the time.

http://i47.photobucket.com/albums/f190/AVTPro/QPnEIAS.jpg

http://i47.photobucket.com/albums/f190/AVTPro/PolyClean.jpg

AVTPro
07-26-2006, 12:43 AM
Hey guys....

Since I went on my June excursion, it's been a little slow getting back to things.
Had some progress and good sucesses with my character head.

http://www.ramjac.com/forum/showthread.php?tid=37&pid=409#pid409

MagicEgger
07-26-2006, 01:38 AM
Hey AVT..

Maya have a type of morphing which does this directly..
I learned How to this cascade effect in EIAS.. but I dont remember now..
You can ask Matt H. we chatted about this.. and he did a simple prj to me.
its simple to implement in EIAS.

Thanks

Tomas

AVTPro
07-26-2006, 06:42 AM
Hey Tomas :)

Yes, I did the sample morph of the eye winking in Maya. They call it inbetweener. It's just a simple button in the Morph Window. This is why I hope to see it added to EI. Yes, I can do it already but I think other EI character animators could use solutions. I wish I had this along time ago.
Seamless eyes is very important to characters. With them, you can choice between cartoony or human.

Thanks Tomas, I will ask Matt, but I hope it's not a replacement animation. I think it would be great to have a plug that can load in a bunch of Cloth models for Maya and morph them.

AVTPro
07-26-2006, 06:55 AM
Just in case you miss the post on the RamJac site.

Sorry for the stretching in ratio.


http://s47.photobucket.com/albums/f190/A...inking.flv (http://s47.photobucket.com/albums/f190/AVTPro/?action=view&current=QPblinking.flv)

http://s47.photobucket.com/albums/f190/A...blink1.flv (http://s47.photobucket.com/albums/f190/AVTPro/?action=view&current=QPblink1.flv)

I am very excited about this. I didn't like that I could ONLY do toon eyes.
Choice is good.

FelixCat
07-26-2006, 07:25 PM
Hi, Alonzo
Nice progress of you qupie... How do you do the blinking of one eye? You did the morph target just for one eye?
BTW. in the second animation, something weird happens behind the ear when blinking...

FelixCat

AVTPro
07-27-2006, 02:13 AM
Hi, Alonzo
Nice progress of you qupie... How do you do the blinking of one eye? You did the morph target just for one eye?
BTW. in the second animation, something weird happens behind the ear when blinking...

FelixCat

Thanks Felix,

This is only a test, so I only did one eye to see if it works as planned. So it's Good To Go (Glory to God)

It's my first test with a character that has the head and eyelids as one part instead of separate cartoony eyes with deformers like Pupil and Frankie. The research I have been doing was initially inspired by EIM "Man~n~Moon" model but the eyes weren't big enough to make an impact. I needed to see if a single multiple target slider would work on a super big bulgey eyes like Qp's. Again, GTG, it works.

http://s47.photobucket.com/albums/f190/AVTPro/?action=view&current=AVT_QPwink.flv
http://s47.photobucket.com/albums/f190/AVTPro/?action=view&current=AVT_QPwinkcornr.flv

Ok, the skinny is it works in Maya. EI Users need a suitable sustainable solution (quoting Malc). In my own words, I believe this to be the last step in making Animator creations on par with modest budget broadcast character animation for commercials. Most character have seamless eyelids. I don't like any of the backfipping that has to do with seamless eyelids. The solution should be simply. I have even seen eyeballs that recede when they blink inorder to avoid the pupils being sliced off by linear morph deformations. Valiant, but ineffective IMO.

Hopefully soon, we will have a simple button that just say morph tweener in the Morph window but til then I see XP playing a large roll in the solution.

As we speak, there are at least two really generous XP scriptwriter working on Qupie's Morph Tweener script. If anyone else is interested in developing script to this purpose of sharing a script that will be published in XP...E-me. I can send them the Maya and EI morph target files.

BTW, the little twitch in the ear is because I accidently move a point when modeling the morphs. The model isn't finished at all. I'm moving on to the body soon. Good luck guys with your MultiMorph scripts.

AVTPro
07-27-2006, 02:28 AM
Hey AVT..

Maya have a type of morphing which does this directly..
I learned How to this cascade effect in EIAS.. but I dont remember now..
You can ask Matt H. we chatted about this.. and he did a simple prj to me.
its simple to implement in EIAS.

Thanks

Tomas


Hey Tomas, I got your files. Yes, we have the same problem and same solutions. Youre info gave me an even clearer idea of what is done and needs to happen.


This option morphs from one target to the other, switching morph anchors
as it goes. For example. If I have an anchor "A", and targets "B, C, D",
Morphing would proceed by going from A,B=0 to B=1. Then B becomes
anchor and we morph from B,C=0 to C=1 then C becomes anchor and we
morph from C,D=0 to D=1.

A single slider controls the morphing even though multiple files are involved.

The morph interface must support more than 10 targets.
The morph interface must allow the reordering of targets.



This will allow EI users to animate heads with lids in one piece or non linear morphs with the use of mutliple targets in one slider.
One slider controls a winking or blinking eye without the eyelids cutting through the concave surface of the eye ball. The lids in the EI project should follow the curvelinear surface of the eyeball. One slider that controls several morphs.

Basically 3 or 4 sequential morphs can equal one morph control. This way the morph can fake curvelinear interpolation.

The script should be simple to implement for non XP saavy users. Just paste the name and the name of the tragets,sliders or morph window slider.

I should be able to make more morphs and run the script for the other side of the face.
As long as it works I will be happy :)

I have included a working Maya file. It uses several morphs to open and close the eyelids, then back to open in one slider. It works fine with the current 3 targets or shape that have been converted to fact files for the EI project.


Duplicate any of the existing head target files to ensure good transition. I added an extra open target in Maya to help keep the form of the face but all must advance in chronological progression.

so you can go head !, 2, 3,2, 1 for open and close. (naming by change in EI but is still sequential)

If you want more form you can add 1,1,2,3,3,2,1 for doubling the open and closing targets. Please "Don't Model" extra targets.

I don't know if the script will need any overlap into each target.
This is how mayas morpher blends.

? maybe so delta insignia.

?=Porig - Pshape

or

P=((?a*Wa)+(?b*Wb)+(?c*Wc)+Porig


I got the equation for the Maya morpher out of a book, "realist creature creation" yesterday and scratched it down in my sketchpad just in case but I don't think XP needs it to do the script.

http://i47.photobucket.com/albums/f190/AVTPro/morpheq.jpg



The way morphs work is through adding the morphs and subracting the original and leaving the difference.

What I don't understand is whether AB, the area between the blending of two morphs is needed when moving from one multimorph target to another (?)

AVTPro
08-01-2006, 10:35 PM
http://www.ramjac.com/forum/showthread.php?tid=37&pid=452#pid452

The EI Tweener Tool has been successufully scripted by super scripter Daniel Hartlenert from Germany.

Thank you.
A friend in need is a friend indeed.

More to come.

To God be the Glory.
from whence cometh mine help.

AVTPro
08-08-2006, 08:39 PM
AVT Pro's ReadyRigs©

presents

"BLINK"
The Tweener Tool©2006


Script by Daniel Hartlehnert
Developed by Alonzo Von Threet

RamjacForum (http://www.ramjac.com/forum/showthread.php?tid=37&pid=477#pid477)


"Praise God from whom all things are possible"

CGTalk Moderation
08-08-2006, 08:39 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.