So, can EI do displacements?

#81

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

#82

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

#83

Hi Loon,

Yes i read did read the documents you sent me :wink:

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

#84

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

#85

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?

#86

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.

#87

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 :slight_smile:

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

R
[/left]

#88

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

#89

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 :slight_smile: )

  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

#90 
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.
#91

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.

#92

Free Wings3D :slight_smile:

#93

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 :slight_smile:

#94

:slight_smile:
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 :frowning:

Good Luck

Loon

#95

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

#96

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

#97

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

Loon

#98

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

#99

Alias does have standalone fbx converters btw.

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

Reuben

#100

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.