Is there any way to load multiple base bake maps on your high poly maps for one bake? I'm setting different maps and it seems to be over-riding them as I set new ones, so it ends up only using one of the maps... Not sure if it's a bug or something I'm doing wrong, or just not possible.
Is there any way to load multiple base bake maps on your high poly maps for one bake? I'm setting different maps and it seems to be over-riding them as I set new ones, so it ends up only using one of the maps... Not sure if it's a bug or something I'm doing wrong, or just not possible.
Export your high poly as separate meshes for each one that needs a unique texture. Then load them all up in xnormal with the proper maps. This is the only way AFIAK.
That's exactly what I'm doing, it's still only baking out with only one map in the end...
And actually after some more testing, if I have 2 high poly models checked, one with a map, and one with none, it just sticks the "Draw using this color" color everywhere, completely ignoring the loaded base bake map...
Of course everything works fine when it's just one high poly model loaded... =\
Using 3.16.4, maybe I should try updating to .6...
I'll be damned if I can get the search to function, so please excuse as I am sure this problem has been asked a number of times in this thread.
This is what I'm getting in the map I'm generating. I've tried changing the front & rear ray tracing from distances of 0.1 to 1000, as well as Cage or No Cage and I keep getting the same thing.
What am I doing wrong here?
Errrr I dunno but I got something looking VERY similar today when I exported my lowpoly which hasn't had the same position like my highpoly version.
Might be wrong though
Alright, so i had thought at one point this had been resolved in XN, but i may be wrong.
In Max and Maya your cage will not split at hard edges creating these artifacts, but in Xnormal it will, giving you lost detail on your edges when you use smoothing groups/hard edges.
Is there some sort of setting where i can change this behaivor? If not, i think its really important to impliment this, as it is right now xnormal doesn't work very well at all when dealing with hard surface stuff and tangent space maps.
Another thing, when using cage in max, it seems like it uses the averaged direction while keeping the edges intact, giving some really strange projection results(skewed details etc). I can get around this by doing 1 bake using the cage, and 1 bake not using cage, but this isnt really a very good solution.
So my idea would be to keep the edges intact, but still use the normal direction from the low poly(weld the edges, but do not average to the normals on the cage). If that is at all possible, i think it would produce much better results.
Hmmm I think I could make the cage continous yep.
Max uses averaged vertex normal as cage's extrussion direction. The question is... what should I use?
If I respect the lowpoly's normal ( as it's doing currently ), the cage will be non-continuous.
Yeah the best thing would be a hybrid of the two, where you keep the cage continuous and also use the low poly's normal direction. But i have no idea if that is really possible. Maybe if you could lock the normal direction before you do anything else?
The obvious problem is that the current way gives good results for details, but not on edges, and the other way distorts your details, but gives great results on the edges. It would be awesome if you could get good results on both with the same method.
If it cant be done, it would be good just to have this as a setting you can toggle in the low poly options. That way we can just do 2 bakes, and combine them in photoshop later.
Actually thinking about this a bit more, a hybrid solution wouldn't solve the problem at all, it would just introduce more problems. Nevermind that then!
An option that you can tick to keep the cage continuous or use the current method would be the best solution.
Actually thinking about this a bit more, a hybrid solution wouldn't solve the problem at all, it would just introduce more problems.
It's a very complitcaed problem to solve, yep.
An option that you can tick to keep the cage continuous or use the current method would be the best solution.
Perhaps I should add an option to use the vertex normal and the cage distance.... so the cage will be used only to limit the ray distance but not the ray direction.
I think just having an option so the cage works like max(averaged) is best.
So... should I modify the existing code to use an "averaged" cage? Or to ADD an option for that? Currently xNormal breaks the cage using the vertex normal... but I'm not sure if to allow a non-continuous cage is good or not.
make an option and the "average" being the default way
unless its too ugly to keep both stuff in at the same time. You may never know if the split isnt useful for some stuff... and an option would allow people to find out
Add an option, the current way is absolutely useful for some stuff. You tend to get more accurate details with the current way(less skewed or bent details). So its good to bake both ways, and combine them in photoshop. I've been doing this in max with very good results. I would make the averaged option the default one, but definitely keep the current method as well.
Heh just about to post this and you already have a new version to try. Was getting these strange results in 3.16.6.42
The cage export was picking up parts of the mesh outside the parts individual cage. As you can see it was xnormal alone. Max cant do crapola with real deep insets, that's why I love your program.
Ok, I found several problems with the model.
First at all, I recommend you to check in the "Lock light to camera" to see better the fails:
The cage must cover the highpoly mesh completely. You need to extrude a bit more the cage vertices near the chair's arms.
Same for the chair's wheels.
Need to extrude a bit more the cage near that part so the highpoly mesh is covered by the cage completely.
TJunctions aren't recommended. You need to tessellate the chair's back part and the union and to join the vertices there.
Another T-junction.
That X part on the bottom part of the seat piece is placed in a way that causes more and more T-junctions!
Your lowpoly model is self-colliding. That will cause weird things when creating the normal map because the cage will have some planes colliding theirself. Tessellate and move a few vertices to avoid that.
All you're problems are caused by T-junctions, which makes the cage to self-collide.
Jogshy, I was aware of most of those (repeat/mirror areas, so their uvs are off the page, so didn't bother). As for model hitting it self, are not seen mostly or areas I intended to clean up afterwords. The issue is what I circled, which are not dealing with the problems you found. Though i appreciate your effort.
Its like for example the seat is picking up part of the headrest, and the headrest is picking up part of the seat.
Again, if you look at the output of the max versus xnormal file above, with the same cage, there is something xnormal is interpreting different in those areas.
I think 3dsmax uses a closest ray hit policy by default. xNormal uses a furthest one do deal with floating geometry. That's why the normal map from 3dsmax is different than the generated with xNormal.
If you unheck the "Use closest hit on ray fail" option in xNormal you'll see lots of rays missing hit. Render also a "Wireframe and ray fails" map in xNormal and you'll see this too.
The problem are the zillion of T-junctions in the model. A T-junction causes the cage to self collide, to mess the ray distance and they also make tons of Z-fighting artifacts with low-precision depth buffers. You need to get rid of all the T-junctions in the model. Once that is done, sure the cage covers completely the highpoly mesh ( move some vertices on the cage or extrude them a bit more ).
Yes, again the parts where is not covering the model are mirror parts, they aren't even on the UV layout since Im only using one side, or you would have uvs overwriting themselves. Is it better just to delete those portions of the mesh instead on the low poly?
Are you saying its the t junctions causing this error of distance? Even though these aren't the same subobject? I also did a test with just the seat exported as an example, and it still was picking up the headrest. Unless the seat subobject itself has t-junctions. I guess I will have to live it then. I will combine the max with your output. I have to make these as low as possible and that excess geometry does me no good with final count.
Are you saying its the t junctions causing this error of distance? Even though these aren't the same subobject?
Not only the error of distance but also some z-fighting.
About subobjects... does not matter.... xNormal does not see subobjects... just complete mesh files.
T-junctions on the lowpoly model cause an error distance due to cage face overlap. The rays won't know well where to start/stop.... they intesect theirself.
ZFighting is due to very close (coplanar or intersecting ) surfaces. It's specially bad if you put your models in game consoles with a low-precision Zbuffer.
T-junctions = very bad in a mesh model. A total crash in case of the cage.
Your problems are derived from a combination of T-junctions and "floating geometry". The T-functions just need some planning, tessellation and vertex welding. The "floating geometry" needs also some planning or to render the normal maps separately for each part.
That reminds me I should add a note about cage T-junctions in the documentation.
So this I hope shows its not t-junctions causing this error?
Are you saying the high mesh needs to be one complete sealed object? Is that even feasable a polycount?
If you separate each portion of the high poly out, the problem is when you need the AO rendering. It no longer will self shadow between portions. Or if you render a displacement map with auto, it wont take into account the full geometry size. Or am I missing something? Separating the low poly into portions as I have already tested does not correct this error.
This is for a PC item, with a crappy engine. We need as low as poly as possible. T-junctions may make you scrounge, but is it realistic to stipulate they cant be used at all? With the variety of projects types out there? Especially when other renders can? Again, I don't think anyone is asking for perfection, and we all know we have to clean up normal maps to some degree or other afterwords.
Just a note: the SBM exporter can manage only TRIANGLES. If you use quad (Eidtable Poly) meshes, the cage won't be exported. That means you need to put an Edit Mesh modifier over your Edit Poly... and then a Projection modifier over the Edit Mesh.
T-junctions are PURE EVIL in the cage.... however, you're right. There's also other problem:
you want to compute the normal map for a concrete chair object ... but its cage is hitting parts on the highpoly mesh you don't want ( the arms and the X- on bottom ).
The cage ( in red ) you setup needs to be less extruded so it does not hit any undesired parts.
Another thing you could do is to separate your highpoly and lowpoly model in several FILES:
Then render the parts separately.... and compose them in a program like Photoshop.
OR
modify the model geometry so you can extrude the cages without requiring much precision.... space more the sub-objects or join them using large screws or pads...
If you separate each portion of the high poly out, the problem is when you need the AO rendering. It no longer will self shadow between portions.
Yep, that's a problem... and it's very difficult to solve currently if you use cages... BUT, fortunately, for AO you don't need cages really because the occlusion rays should be fired from the "sky"... which is always "outside" the model.
On the other hand, if your lowpoly model is just the subdiv0 of the highpoly model, you can use the MatchUV feature to avoid the need for cages or ray distances.
For xn4 I'm gonna allow the user also to define which parts cast/receives shadows from other parts in the model.
Or if you render a displacement map with auto, it wont take into account the full geometry size. Or am I missing something?
You can also use manual normalization in case you render it by parts. Advice: Set the distances relative to the object's radius. That will be a good value to start.
The MatchUV feature can help a lot also if you used subdivision.
This is for a PC item, with a crappy engine. We need as low as poly as possible. T-junctions may make you scrounge, but is it realistic to stipulate they cant be used at all?
I personally don't like T-junctions, but if you really need them and they're giving you some headaches using cages ... the just don't use cages. You can use other methods to control the rays in xNormal: constant uniform ray distances, ray blockers or the matchUV feature. Cages are only a way to work... but there are other ways.
On the other hand, normal mapping is supposed to be a next-gen technique... not a technique to be used in a PS-One, a PSP or a mobile phone which requires low polycounts. For a PC you should not see a dramatical FPS reduction by just fixing some t-junctions.
Well... I'm just a programmer... perhaps some artist here can give you some advices to render that chair easier. My recomendation for this concrete model is to render the normal maps separately for each sub-object... and for the AO just UNcheck the "limit ray distance" option and render the objects together.
Thanks for the reply Jogshy, unfortunately there would be no way to have a cage not hitting other portions (though again, the errors I circled werent with the portions hitting). I can always and have juut cleaned up the "outlines" created by intersecting pieces afterwords. Its not a big deal. Outlines are easier to clean in each channel than whole sections being picked up from other portions of the model.
I do export my meshes as meshes FWIW.
I will attempt your AO suggestion and just separate these parts out for the normal map. Per the displacement and setting it manually. Your right, but I more render those "just in case" we decide to throw in parallax at some point. So I have no set distance I can use, and since these are used in more than one project with different scaling.. even more a headache.
*smallest violin playing just for me
Thank you none the less for your time and effort on this tool.
finally decided to learn to use this thinger.
This is probably a totally noob question,
but how do i get the normalmaps from XN to show up properly in max? I assume i have to flip some channels?
By the way Jogshy, It's a sick tool, but about the new cage features, I tried standard cage and averaged cage and didnt really notice a difference, but my lowpoly is exploded, so... I dont know if it would make a difference anyway. I'm just correcting the seams in PS.
but how do i get the normalmaps from XN to show up properly in max? I assume i have to flip some channels?
Yep, flip green channel in Photoshop or just use a swizzling of X+Y-Z+ when you generate the normal map from xNormal.
Btw, caution with the Max's D3D bump shader... it's very bugged in old versions(<=max9) and it generates a lot of seams and UV mirroring problems. Better use these ones:
finally decided to learn to use this thinger.
This is probably a totally noob question,
but how do i get the normalmaps from XN to show up properly in max? I assume i have to flip some channels?
By the way Jogshy, It's a sick tool, but about the new cage features, I tried standard cage and averaged cage and didnt really notice a difference, but my lowpoly is exploded, so... I dont know if it would make a difference anyway. I'm just correcting the seams in PS.
If you've manually detached faces, you wont see any difference. I think that may be your problem. You should be creating your hard edges with smoothing groups, and only "exploding" parts of your mesh that are actually separate chunks, not cutting off faces arbitralily(correct me if i'm wrong, this seemed like what you were doing from your WIPS?).
Also, if you have to touch up your seams in PS you're doing something wrong, and can likely save a lot of time by figuring out your bakes first.
Edit: a little more on baking methods, seams, all this stuff etc can be found here:
So this I hope shows its not t-junctions causing this error?
Are you saying the high mesh needs to be one complete sealed object? Is that even feasable a polycount?
If you separate each portion of the high poly out, the problem is when you need the AO rendering. It no longer will self shadow between portions. Or if you render a displacement map with auto, it wont take into account the full geometry size. Or am I missing something? Separating the low poly into portions as I have already tested does not correct this error.
This is for a PC item, with a crappy engine. We need as low as poly as possible. T-junctions may make you scrounge, but is it realistic to stipulate they cant be used at all? With the variety of projects types out there? Especially when other renders can? Again, I don't think anyone is asking for perfection, and we all know we have to clean up normal maps to some degree or other afterwords.
The best solution here is to make an "exploded" version of your mesh, where you move in both the bake mesh and the highpoly, the parts that will intersect, just move them some common unit, and bake it all at once. This is much faster than doing multiple bakes or whatever.
The best solution here is to make an "exploded" version of your mesh, where you move in both the bake mesh and the highpoly, the parts that will intersect, just move them some common unit, and bake it all at once. This is much faster than doing multiple bakes or whatever.
Awesome job getting the average normals on hard edge thing working Santi!!!
Just had a go and it seems to work very nicely.
EQ: I hadn't thought of just rendering both methods then combining them in Photoshop. Genius!!
The way I usually fix the distortion is adding extra "support" edges along the hard edge when I bake to guide the rays. But not keep them in the final low poly which works well. But sometimes it's not that simple to add extra loops so ill try the Photoshop method in those cases.
Awesome job getting the average normals on hard edge thing working Santi!!!
Just had a go and it seems to work very nicely.
EQ: I hadn't thought of just rendering both methods then combining them in Photoshop. Genius!!
The way I usually fix the distortion is adding extra "support" edges along the hard edge when I bake to guide the rays. But not keep them in the final low poly which works well. But sometimes it's not that simple to add extra loops so ill try the Photoshop method in those cases.
Yeah this method is SUPER easy, just requires twice the baking time, but hey, go make a sandwich or something.
Alright, since converting OS maps from max format to maya/XN format is not nearly as simple, i figured i'de start up a post here on the correct way to convert maps, as well as try to figure out the correct settings to use when rendering in max for xn/maya format OS maps.
Here is a quick example(kaskad's bullet) in toolbag of how the max rendered OS map is incorrect.
And here are the different maps
Now, if we analize the difference between the maps here, we should be able to come up with a method to convert from one to the other.
If we break it down into the specfic color channels, we see that:
Red is the same
Green in xn is the same as blue in max
Blue in xn is Green in max, but inverted.
So, to convert a Max OS map to Maya/XN format, we need to do this
1. Copy the green into a seperate file
2. Copy the blue into the green
3. Invert the green channel that was pasted into a new image, and copy that into the blue.
There, that should solve it, you should now have something that looks like this:
Now, the final thing to figure out is which swizzle settings do we change to come up with the same result in Max/NX, now that is where i have no clue.
Excuse my newbiness but is there a way to bake normals properly with a model that's fully mirrored horizontally? I've tried to achieve this with xNormal but the normals get warped near the center seam of the model. I have applied the mirroring in my low poly mesh when I bake but that doesn't help at all.
First of all thanks for the great program jogshy. The new max(averaged) cage works like a charm. I was forced to bake the hard edged stuff in max previously.
I dunno if this is discussed before (I tried the search) Is there feature to set the the background color for each bake separately ex. white for ao and 128 128 255 RGB for normals etc. It would save some extra time from doing it manually in photoshop.
Also I think GUI would also need a touch of some decent graphic design. It works very well, but it looks a bit outdated right now. Not that it matters that much.
There is something I can't quite wrap my head around in Xnormal. In the 3D viewer window (that I don't use much usually, hence I am not very familiar with it...) there is an option to inflate the lowpoly to make it a fat ray cage. It's great and very user friendly, but, how do I put this new and nice cage in the 'cage' slot for the lowpoly bake?
I see the 'save meshes' button but it is unclear what it does, seems like it saves the low, high and cage all at the same time?
All I am looking for really is a 'export current cage' button, or a 'use currently defined cage as bake cage' tickbox.
There is something I can't quite wrap my head around in Xnormal. In the 3D viewer window (that I don't use much usually, hence I am not very familiar with it...) there is an option to inflate the lowpoly to make it a fat ray cage. It's great and very user friendly, but, how do I put this new and nice cage in the 'cage' slot for the lowpoly bake?
I see the 'save meshes' button but it is unclear what it does, seems like it saves the low, high and cage all at the same time?
All I am looking for really is a 'export current cage' button, or a 'use currently defined cage as bake cage' tickbox.
Thanks!
pior: Yup. It will save both the highpoly and the lowpoly with your tweaked cage and autoassign them if you want to their correct slots for you after you do this. I don't think there is a way to only export the lowpoly cage... so you end up with 2 extra files after your tweaking.
Here is a link for an old tut about the 3d viewer cages:
Also I think GUI would also need a touch of some decent graphic design. It works very well, but it looks a bit outdated right now. Not that it matters that much.
The xn3 UI gonna be replaced completely in xn4. I'm programming a standard native-look UI with an integrated 3D viewport ( which can be disabled so no resources will be wasted ).
Btw, the xn4's portability is making me crazy... I need to test the each thing 16 times ( windows XP + windows Vista + ubuntu + openSUSE + MacOSX 10.4 + MacOSX 10.5 + openSolaris 2008.11 + Solaris 10 ) and then 2X ( x86, x64 )... a pain.
It's great and very user friendly, but, how do I put this new and nice cage in the 'cage' slot for the lowpoly bake?
I see the 'save meshes' button but it is unclear what it does
Unfortunately, cages cannot be saved separately. That could cause topology conflicts.
The mechanish to achieve that is just to press the "Save meshes" button. Then a dialog appears asking you about replacing the current files with the new cage.
If you ask NO then the files will be saved in the same folder than the meshes you're currently using with the names a bit tweaked ( for example, if you use a lowpoly mesh in c: \myMeshes\chair.obj then a new file will be created in c: \myMeshes\chair_chair.sbm ).... so you can exit the 3d viewer and then assign the SBM file manually instead of the chair.obj in the lowpolys list )... better just answer YES to the dialog and save you a headache.
Replies
Export your high poly as separate meshes for each one that needs a unique texture. Then load them all up in xnormal with the proper maps. This is the only way AFIAK.
And actually after some more testing, if I have 2 high poly models checked, one with a map, and one with none, it just sticks the "Draw using this color" color everywhere, completely ignoring the loaded base bake map...
Of course everything works fine when it's just one high poly model loaded... =\
Using 3.16.4, maybe I should try updating to .6...
Errrr I dunno but I got something looking VERY similar today when I exported my lowpoly which hasn't had the same position like my highpoly version.
Might be wrong though
In Max and Maya your cage will not split at hard edges creating these artifacts, but in Xnormal it will, giving you lost detail on your edges when you use smoothing groups/hard edges.
Is there some sort of setting where i can change this behaivor? If not, i think its really important to impliment this, as it is right now xnormal doesn't work very well at all when dealing with hard surface stuff and tangent space maps.
Another thing, when using cage in max, it seems like it uses the averaged direction while keeping the edges intact, giving some really strange projection results(skewed details etc). I can get around this by doing 1 bake using the cage, and 1 bake not using cage, but this isnt really a very good solution.
So my idea would be to keep the edges intact, but still use the normal direction from the low poly(weld the edges, but do not average to the normals on the cage). If that is at all possible, i think it would produce much better results.
Max uses averaged vertex normal as cage's extrussion direction. The question is... what should I use?
If I respect the lowpoly's normal ( as it's doing currently ), the cage will be non-continuous.
The obvious problem is that the current way gives good results for details, but not on edges, and the other way distorts your details, but gives great results on the edges. It would be awesome if you could get good results on both with the same method.
If it cant be done, it would be good just to have this as a setting you can toggle in the low poly options. That way we can just do 2 bakes, and combine them in photoshop later.
An option that you can tick to keep the cage continuous or use the current method would be the best solution.
Perhaps I should add an option to use the vertex normal and the cage distance.... so the cage will be used only to limit the ray distance but not the ray direction.
Limiting the distance isnt really the problem, its losing detail on the edges.
unless its too ugly to keep both stuff in at the same time. You may never know if the split isnt useful for some stuff... and an option would allow people to find out
Feel free to test it.
thx
The cage export was picking up parts of the mesh outside the parts individual cage. As you can see it was xnormal alone. Max cant do crapola with real deep insets, that's why I love your program.
I will go download this new beta to see if fixes.
here is the exported mesh from max with the cage.
http://www.oxynary.com/downloads/lowchair.zip
Yep, I forgot to increase the version for the 3.16.7 heheh
First at all, I recommend you to check in the "Lock light to camera" to see better the fails:
The cage must cover the highpoly mesh completely. You need to extrude a bit more the cage vertices near the chair's arms.
Same for the chair's wheels.
Need to extrude a bit more the cage near that part so the highpoly mesh is covered by the cage completely.
TJunctions aren't recommended. You need to tessellate the chair's back part and the union and to join the vertices there.
Another T-junction.
That X part on the bottom part of the seat piece is placed in a way that causes more and more T-junctions!
Your lowpoly model is self-colliding. That will cause weird things when creating the normal map because the cage will have some planes colliding theirself. Tessellate and move a few vertices to avoid that.
All you're problems are caused by T-junctions, which makes the cage to self-collide.
I hope it helps.
Its like for example the seat is picking up part of the headrest, and the headrest is picking up part of the seat.
Again, if you look at the output of the max versus xnormal file above, with the same cage, there is something xnormal is interpreting different in those areas.
If you unheck the "Use closest hit on ray fail" option in xNormal you'll see lots of rays missing hit. Render also a "Wireframe and ray fails" map in xNormal and you'll see this too.
The problem are the zillion of T-junctions in the model. A T-junction causes the cage to self collide, to mess the ray distance and they also make tons of Z-fighting artifacts with low-precision depth buffers. You need to get rid of all the T-junctions in the model. Once that is done, sure the cage covers completely the highpoly mesh ( move some vertices on the cage or extrude them a bit more ).
Are you saying its the t junctions causing this error of distance? Even though these aren't the same subobject? I also did a test with just the seat exported as an example, and it still was picking up the headrest. Unless the seat subobject itself has t-junctions. I guess I will have to live it then. I will combine the max with your output. I have to make these as low as possible and that excess geometry does me no good with final count.
About subobjects... does not matter.... xNormal does not see subobjects... just complete mesh files.
T-junctions on the lowpoly model cause an error distance due to cage face overlap. The rays won't know well where to start/stop.... they intesect theirself.
ZFighting is due to very close (coplanar or intersecting ) surfaces. It's specially bad if you put your models in game consoles with a low-precision Zbuffer.
T-junctions = very bad in a mesh model. A total crash in case of the cage.
Your problems are derived from a combination of T-junctions and "floating geometry". The T-functions just need some planning, tessellation and vertex welding. The "floating geometry" needs also some planning or to render the normal maps separately for each part.
That reminds me I should add a note about cage T-junctions in the documentation.
See example
File of the quad seat (use with high of other).
File:
http://www.oxynary.com/downloads/lowchairquads.zip
(use with high one from original zip)
So this I hope shows its not t-junctions causing this error?
Are you saying the high mesh needs to be one complete sealed object? Is that even feasable a polycount?
If you separate each portion of the high poly out, the problem is when you need the AO rendering. It no longer will self shadow between portions. Or if you render a displacement map with auto, it wont take into account the full geometry size. Or am I missing something? Separating the low poly into portions as I have already tested does not correct this error.
This is for a PC item, with a crappy engine. We need as low as poly as possible. T-junctions may make you scrounge, but is it realistic to stipulate they cant be used at all? With the variety of projects types out there? Especially when other renders can? Again, I don't think anyone is asking for perfection, and we all know we have to clean up normal maps to some degree or other afterwords.
T-junctions are PURE EVIL in the cage.... however, you're right. There's also other problem:
you want to compute the normal map for a concrete chair object ... but its cage is hitting parts on the highpoly mesh you don't want ( the arms and the X- on bottom ).
The cage ( in red ) you setup needs to be less extruded so it does not hit any undesired parts.
Another thing you could do is to separate your highpoly and lowpoly model in several FILES:
arms_low.sbm
arms_high.sbm
seat_low.sbm
seat_high.sbm
wheels_low.sbm
wheels_high.sbm
etc etc
Then render the parts separately.... and compose them in a program like Photoshop.
OR
modify the model geometry so you can extrude the cages without requiring much precision.... space more the sub-objects or join them using large screws or pads...
Yep, that's a problem... and it's very difficult to solve currently if you use cages... BUT, fortunately, for AO you don't need cages really because the occlusion rays should be fired from the "sky"... which is always "outside" the model.
On the other hand, if your lowpoly model is just the subdiv0 of the highpoly model, you can use the MatchUV feature to avoid the need for cages or ray distances.
For xn4 I'm gonna allow the user also to define which parts cast/receives shadows from other parts in the model.
You can also use manual normalization in case you render it by parts. Advice: Set the distances relative to the object's radius. That will be a good value to start.
The MatchUV feature can help a lot also if you used subdivision.
I personally don't like T-junctions, but if you really need them and they're giving you some headaches using cages ... the just don't use cages. You can use other methods to control the rays in xNormal: constant uniform ray distances, ray blockers or the matchUV feature. Cages are only a way to work... but there are other ways.
On the other hand, normal mapping is supposed to be a next-gen technique... not a technique to be used in a PS-One, a PSP or a mobile phone which requires low polycounts. For a PC you should not see a dramatical FPS reduction by just fixing some t-junctions.
Well... I'm just a programmer... perhaps some artist here can give you some advices to render that chair easier. My recomendation for this concrete model is to render the normal maps separately for each sub-object... and for the AO just UNcheck the "limit ray distance" option and render the objects together.
I hope it helps.
I do export my meshes as meshes FWIW.
I will attempt your AO suggestion and just separate these parts out for the normal map. Per the displacement and setting it manually. Your right, but I more render those "just in case" we decide to throw in parallax at some point. So I have no set distance I can use, and since these are used in more than one project with different scaling.. even more a headache.
*smallest violin playing just for me
Thank you none the less for your time and effort on this tool.
Any comment on the new average/weld cage features, pls? Can you render better the non-organic models now?
thx
This is probably a totally noob question,
but how do i get the normalmaps from XN to show up properly in max? I assume i have to flip some channels?
By the way Jogshy, It's a sick tool, but about the new cage features, I tried standard cage and averaged cage and didnt really notice a difference, but my lowpoly is exploded, so... I dont know if it would make a difference anyway. I'm just correcting the seams in PS.
Btw, caution with the Max's D3D bump shader... it's very bugged in old versions(<=max9) and it generates a lot of seams and UV mirroring problems. Better use these ones:
http://www.bencloward.com/resources_shaders.shtml
If you've manually detached faces, you wont see any difference. I think that may be your problem. You should be creating your hard edges with smoothing groups, and only "exploding" parts of your mesh that are actually separate chunks, not cutting off faces arbitralily(correct me if i'm wrong, this seemed like what you were doing from your WIPS?).
Also, if you have to touch up your seams in PS you're doing something wrong, and can likely save a lot of time by figuring out your bakes first.
Edit: a little more on baking methods, seams, all this stuff etc can be found here:
http://boards.polycount.net/showthread.php?p=905227#post905227
The best solution here is to make an "exploded" version of your mesh, where you move in both the bake mesh and the highpoly, the parts that will intersect, just move them some common unit, and bake it all at once. This is much faster than doing multiple bakes or whatever.
That makes too much sense!
Thanks.
Just had a go and it seems to work very nicely.
EQ: I hadn't thought of just rendering both methods then combining them in Photoshop. Genius!!
The way I usually fix the distortion is adding extra "support" edges along the hard edge when I bake to guide the rays. But not keep them in the final low poly which works well. But sometimes it's not that simple to add extra loops so ill try the Photoshop method in those cases.
Yeah this method is SUPER easy, just requires twice the baking time, but hey, go make a sandwich or something.
AO smiley example old -> 64s
AO smiley example new -> 33s
that's a 200% on my computer :P
Here is a quick example(kaskad's bullet) in toolbag of how the max rendered OS map is incorrect.
And here are the different maps
Now, if we analize the difference between the maps here, we should be able to come up with a method to convert from one to the other.
If we break it down into the specfic color channels, we see that:
Red is the same
Green in xn is the same as blue in max
Blue in xn is Green in max, but inverted.
So, to convert a Max OS map to Maya/XN format, we need to do this
1. Copy the green into a seperate file
2. Copy the blue into the green
3. Invert the green channel that was pasted into a new image, and copy that into the blue.
There, that should solve it, you should now have something that looks like this:
Now, the final thing to figure out is which swizzle settings do we change to come up with the same result in Max/NX, now that is where i have no clue.
the uvs for the side your baking are in uv tile 1 and the other half of the models uvs are in the next unit, I had the same problem here http://boards.polycount.net/showthread.php?t=60615&highlight=pooh
Thanks a lot! Will try this out.
Edit: Got it to work, thanks for the help!
I dunno if this is discussed before (I tried the search) Is there feature to set the the background color for each bake separately ex. white for ao and 128 128 255 RGB for normals etc. It would save some extra time from doing it manually in photoshop.
Also I think GUI would also need a touch of some decent graphic design. It works very well, but it looks a bit outdated right now. Not that it matters that much.
Thanks
There is something I can't quite wrap my head around in Xnormal. In the 3D viewer window (that I don't use much usually, hence I am not very familiar with it...) there is an option to inflate the lowpoly to make it a fat ray cage. It's great and very user friendly, but, how do I put this new and nice cage in the 'cage' slot for the lowpoly bake?
I see the 'save meshes' button but it is unclear what it does, seems like it saves the low, high and cage all at the same time?
All I am looking for really is a 'export current cage' button, or a 'use currently defined cage as bake cage' tickbox.
Thanks!
pior: Yup. It will save both the highpoly and the lowpoly with your tweaked cage and autoassign them if you want to their correct slots for you after you do this. I don't think there is a way to only export the lowpoly cage... so you end up with 2 extra files after your tweaking.
Here is a link for an old tut about the 3d viewer cages:
http://www.xnormal.net/DownloadFile.aspx?fileID={95CCB958-7931-499a-A8AE-84C3289D214A}
Btw, the xn4's portability is making me crazy... I need to test the each thing 16 times ( windows XP + windows Vista + ubuntu + openSUSE + MacOSX 10.4 + MacOSX 10.5 + openSolaris 2008.11 + Solaris 10 ) and then 2X ( x86, x64 )... a pain.
Unfortunately, cages cannot be saved separately. That could cause topology conflicts.
The mechanish to achieve that is just to press the "Save meshes" button. Then a dialog appears asking you about replacing the current files with the new cage.
If you ask NO then the files will be saved in the same folder than the meshes you're currently using with the names a bit tweaked ( for example, if you use a lowpoly mesh in c: \myMeshes\chair.obj then a new file will be created in c: \myMeshes\chair_chair.sbm ).... so you can exit the 3d viewer and then assign the SBM file manually instead of the chair.obj in the lowpolys list )... better just answer YES to the dialog and save you a headache.