Yeah it can be fixed by editing in ps, I've actually used zbrush to paint in 3d on my low poly models a couple times to fix seams too, works very well. I was just wondering what the issue is, because i've seen programs that can generate the maps without any seams... I dont think i got any seams when using ORB or doom3....
I just did another test, ignore the errors on ears and nose, thats just cage issues... Seems like im getting a lot of smoothing errors here, should i be manually triangulating my mesh before running it through this program?
Well, you should definitely manually triangulate your lowpoly mesh I think. Or at least be sure that any non-planar quads have their dividing edge running in the right direction.
I would try welding the horizontal forehead seam and move the eye UVs down to the bottom of the map, a bit more stretching in that area is much more preferable to having a big-ass UV seam there. See what happens after you do that and sort out the cage?
Which smooth-normals xNormal option are you using for the lowpoly model? Average CW, Average CCW or Use exported normals? I would suggest you to use one of the Average CCW option ( or Average CW if is a .lwo ) because it autosmooths the normals using face averaging to solve this.
Also, sure to collapse all the meshes into one using the same material before to export as OBJ. Sure too the vertices and UVs are weld in the zones you have the seams.
Also caution because some non-Maya OBJ exporters really mess the vertex normals ( like 3DSMAX... make a cube.. export mesh with vertex normals and see the disaster editing the .obj with the notepad... All the vertex normals will be (0,0,-1) ! )
If you still have problems with smoothing try to manually triangulate the mesh ( Maya->Polygons->Triangulate or sometring like that ). And if still have problems then is my fault or a bug hehe
Im using .obj exported from Modo, didnt know there were any smoothing options so ill check that when i get a chance, and its all 1 material with merged verts. Maybe i should try .lwo, do you know if your program supports modo .lwos or would i need to export to lightwave .lwo?
Ooooh Modo! Try to use an OBJ mesh using the xNormal's smooth normals "Average CCW"(or CW, depends if your faces are defined clockwise or counterclokwise) option to test if the seams can be eliminated.
I don't like too much the 3DS/LWO formats because they don't export vertex normals accurately ( it only exports per-face smooth groups ). xNormal supports Lightwave 6.5 or above ( known as LWO2 ) format, not sure what kind of LWO exports Modo sorry.
Milkshape 3D (.ms3d) can export vertex normals very good as well as Softimage XSI ( dotXSI files ). You can try to export in these formats if you have problems too.
The normals are completely toast, it looks like the program is giving precedence to the innermost surface if there are multiple in range. For a comparison, with an ORB-generated normalmap the result looks like this:
The files are .objs generated with Blender, should I email them to you?
Fire rays from the inner cage to the outter cage ( if cages are enabled ). Fartest hit is taken always. If rays fails hit then use closest hit. If this fails use lowpoly normal.
Are you using cages? If not, have you set a good outter and inner distance ( mesuring with a 3dsmax "tape" or something )? Are you using any "swizzle" coord to change model coordinate system? Are you using exported normals or averaging them? Is your model using more than one material by mesh? Do you see the "XXXXXX rays failed" after generating the normal map? Yep yep, it appears is taking closest hit for some motive ( see the nipples, cloth floating geometry is being ignored or something like that ), prolly because is missing some hits.
Ok too much questions... Send me the model ( lowpoly obj + highpoly obj + xml settings + .cag files ) if ya want and I will try to answer asap
This time I changed completely the ray heuristics. Now I am using a method that allows to forget forever the ray distances, so I disabled the cages functionality because were not needed ( more tests needed but I think cages and distances are history! )
Also changed the heightmap algorithm to be more accurate, specially at triangle edges.
Added the glow effect for emissive texture with a slider to control intensity and a checkbox to disable it. See a preview image:
Also put an option to hide lowpoly/highpoly meshes inside the viewer.
Solved a very bad crash rendering normal maps with multiple meshes.
Now it allows too to launch the viewer without lowpoly models loaded if you wanna see only the highpoly meshes as requested.
Added numerical values to some 3D viewer controls.
Now the viewer uses alpha sorting per triangle ( very accurate but can be slow sometimes so beware the # of alpha-texture polygons you put... ). Now the entire acid example is alpha-sorted ( eyes are semi-transparent and reflective )
Changed too that ugly green V button by a new aqua one ( thx MoP for the inspiration ). Hopefully in a few I will let you to use skins for xNormal.
Changed tons of things so I bet some error/bug is there waiting to assault you at some point
Will try answer you by Monday ( this weekend I wanna rest some )
Btw KDR, your Hitomi now should render OK because I used her to do the tests You should rotate the model (or use X+Z+Y- swizzle) a few because I saw her in floor in the model you e-mailed me heheh ( use X to right, Y to up, Z growing from far to you to fit the 3D viewer well )
Is there any way that I could make the effect less "pixelly"? It looks like it's using some sort of extra texture overlayed onto the screen, but it seems very low-res... is that a problem with my graphics card or a setting I could change? I think if the effect was smoother it'd be perfect.
Also, I haven't tested a lot to make sure of this, but does the Specular texture use colour, or is it just black and white? I've got a coloured Specular map on that screenshot, but it seems all the highlights are white no matter what colour the specular map is. Again this might be my fault, I'm not sure - I'll do some more tests
Yep yep, I am using a little crappy shader atm for the glow ( and very low resolution.. 128x128 texture ). In the next version I will let you control the pixel range extent and the posteffect texture size for more control.
In theory, the specular texture uses RGB for specular modulation ( you can use too the light specular color for even more control ). If you pass it a texture with alpha the .A will be used to control the specular power ( shininess, variable per-pixel specular power.. 255 means very shiny, 0 means a biiiiig highlight )... I think I mentioned it in the docs, not sure. Specular can be a little weird too depending on the driver implementation due to a funciton called "POW"... Some cards allows to use something like X^2.7189 ( which is good ), but others just cap the decimals and provokes not very good specular btw. Also the Radeons 9XXX can't use floating point textures for the normalmap which can degrade a lot the specular too. Or perhaps is my fault because the xNormal shaders are passing the 100 HLSL lines lol!
If you can take two screenshots in a Radeon 9500 and in a GeForce6XXX/7XXXX/Radeon X1000 you will notice a brutal quality improvement due to floating point normalmap textures ( see specially the environment reflection quality too )
As you can see some parts of the model have what seems like reflections of other parts of the model on them. Same issue I previously had with the occlusion maps. Since it doesn't seem to happen to you, is there something hardware reliant in the algorithm you're using? Or does the current algorithm simply not have a limit for the distance between lowpoly and highpoly surface?
If it helps my specs are: Athlon 64 3000+, 1024 MB RAM (dual channel), GeForce 6800, Windows 2000.
This is the Hitomi I am getting in the viewer ( normal+occlusion) with the default options:
I think was good because just saw her from the front view... But yes, you're right... There is a problem when I see her from the right/left ... It appears the new heuristics failed 8( See the parts marked with a circle in normal map:
Well, if you look at the side of the dress on the normal map, it appears the arm is being rendered onto the skirt UVs, presumably because the rays are casting through the arm a long way away, and since that's the furthest surface, it's rendering the arm on top of the skirt which looks a bit weird.
I think the external cage at least is needed so the rays know when to stop and don't go on to other bits of highpoly geometry.
Basically added back the cages and forgot the experimental crappy old method forever Also refit a few the glow as MoP suggested, solved problems with cages from older versions and some other minor improvements. I think it should be well now!
I was trying to render Hitomi but I'm too lazy to set the cages in the hands... Noticed that model needs a lot of cage tweak ( specially at the inner one ) altought it can be almost ok using the new "Closest if ray fails" feature... But was great, that model teached a lot to me. Will try to setup it in a few and put some screenshots if I get it well but my artwork skills sux badly
Oh btw, I am thinking about making a video to teach how to setup well the cages.. Do you know any good and free program to capture a video from the screen pls?
I recommend you the new version because the v3.4.x were not using really the cages ( there was a bug and cages weren't loaded correctly ). Also the v3.5.0 ray algorithm was a little weird... So hope the v3.5.1 solves all.
Yep yep this is the normalmap is generating now after tweaking a few the cages:
Is good now but the hands tweaking was a bit hard hehe
I can't wait to see that sexy model finished KDR! Btw, you can test if ya want the alpha blending sort in the viewer for the hair
If all works now then I can start coding the new features for the v3.5.2 , like the multiple vertex selection using a rectangle area, the diffuse cubemap lighting ( low frequency lighting for PRT ) and the ASE support! ( and to start thinking in soft-area-penumbra-shadows and the new normalmap multisampling for the v3.6.0.. omg HEADACHE )
Got some more time to play with it, dosent matter what smoothing type i set it to it just renders wrong. Its like its getting completely different lighting than the highres is.
Please, first sure you downloaded the v3.5.1 I just put some minutes ago because the 3.4.x had some serious bugs with cages and the v3.5.0 was a few experimental.
Now, it looks like you are NOT checking the "Tangent space" in the Viewer 3D tab... It happens me a lot... Sure you have selected the SAME in the normal map generation tab and in the viewer 3D tab ( tab=the panels that appears when you press the right side buttons )... For example, if you generate the normal map in tangent space sure you ALSO checked the "tangent space" for the viewer... I think it could be that. To sure just don't use tangent space, use object space in BOTH.
See:
Here are the screens of what I get:
Used "Average CCW" smooth normals, object space ( again you need to generate normal map in object space AND then select object space TOO for the viewer.. notice object space is just not-to-check tangent space ) and tweaked the head fast using cages.
DOH, didnt even see an option for that hehe. Your AO is way faster than XSI's and gives better results from what i've seen, i havent used it extensively but it seems to be a huge improvement over what im currently using at work.
Hey do you happen to have aim/icq/yahoo/etc or anything?
Ok so the turning on tangent in 3dviewer optiosn worked, but now i've got another problem. When you get close theres all kinds of artifacts, looks almost like theres unwelded edges here? Cant really tell if they are in your screenshot but it dosent look like it....
Turn on the "show lowpoly tangents" to see the normals on these vertices... If are unwelded then you must see different normals and tangent basis for them ( like very similar axis in a bunch ).
edited: YES, i see that too... When I turn the show tangent basis I see you must weld them better and sure UV's are welded too! See!
If are welded then try to export as dotXSI/LWO and not like OBJ to see if is an exporter problem
Also, don't use tangent space normal maps until you are 100% sure your vertices and UVs are well set, welded and pixel-snapped if possible... Prefer object space for undeformable objects and modelling/uv mapping process. Only use tangent space at the final, when you are previewing the final 3d game engine model... Tangent space is slower and can be conflictive due to the basis computation... If you can, use always the object space normal maps unless you need mirroring or deformable meshes.
Also, try to "relax" UVs on all your models... To see how much "unrelaxed" is your model texcoord use the checked.tga which is provided with xNormal as base texture ( in the xN_examples folder )
See:
As you notice, in those parts the UVs are very unrelaxed and non-countinuous mapped, which causes discontinuities in the tangent basis... You need to weld the vertex positions AND the UVs ( and use pixel-snap is possible)... Also, don't trust in exporters... Once you saved it to a file, edit the .OBJ or .XSI and see there are no degenerated faces , duplicated vertices or strange normals like (-0.000,-0.000,-0.0000) exported. I do a pass ( you can see it in the progress bar saying "Removing illegal geometry" ) to solve a few this but it could't work if the exporter does really bad job Specially, COLLADA exporters are pretty immature and I saw tons and tons of bad data coming in LWOs from non-lightwave programs too!
My favourite format is the stanford PLY exported from Blender ( that's why I exported the acid in that format, because was the best vertex/face-count-optimized ). Then the OBJ exported from Maya and the 3DS exported from 3DSMAX 8. The dotXSI format from XSI 5.1 can be good too.
It can be a bug in xNormal too. Perhaps I should see back the import routines and tangent basis calculation.
edited: Yep, imported your model into Maya, relaxed UVs and welded verts and solved.
Same problem with .lwos, its definately not a problem with the actual geo, most likely modo's exporter or something.... Would it be posible to add in something that will auto weld verts in uvspace that are in exactly the same spot? Or within a tolerance....
Yeah thats definately it, loaded .obj in max, all uv verts were unwelded, so i welded exported and now it works great.
[ QUOTE ]
Would it be posible to add in something that will auto weld verts in uvspace that are in exactly the same spot? Or within a tolerance....
[/ QUOTE ]
Not really.. think in a cube with every face mapped independently! What you mean by "same spot"?
I think there is only a way to sure model contains the correct geometry. Just sure you weld positions and UVs you want ( and always try to relax UV and pixelsnap while you map it ) + triangulate + remove degenerated faces + remove duplicate vertices + reset XForm in 3dsmax8 = the bibble of exporting haha!
Btw, anybody know a good and free video capturer? I wanna make some video tutorials of xNormal pls!
What would the problem with that be? Would only be a problem if you welded the uv verts that were the in the same spot in 3d space, but im only talking about welding them if they are in the same spot in uv space. So edges that need to be split would still remain split. Im pretty sure ORB will do this when you import a model but am not 100% sure.
Ahhhh I understand now.. weld UV's with very equal values with certain error.. I am making that though ( specifically error atm is 0.0001 ) but only form some file formats. But yep yep good idea! I think just need to use a higher one and use it in all mesh file types. Will test it, thx!
By same spot i mean verts that are in the same position, it seems like modo's exported unwelds all the verts in UV space when exporting thus leaving 3 or 4 verts in the same position in every place there should be only 1.
Would be the same thing as going into max, applying a uvunwrap, selecting all the verts and hitting weld from uvunwrap window with a really low tollerance.
Great. Hopefully that will fix it because at the moment i dont have access to 3dsmax on my work machine, so i wouldnt be able to use this program there =(
Hey Jogshy, here's a new screenshot with the creature
Click for fullsize:
Also I got the alpha opacity maps working, as you can see! Thanks
Hey, and I just had another idea for something useful, hopefully not difficult to do:
- When pressing CTRL + right-mousebutton, at the moment the program will rotate the camera around the 0,0,0 point on the grid, yeah? Could you make it rotate around the centrepoint of the mesh, found by some method? For example maybe taking the average of vertex locations and setting that as the centre of the camera rotation.
Because at the moment, my guy's feet are at 0,0,0 - so when I rotate the camera with this CTRL method, it ends up looking at just his feet and legs instead of the whole model
Jogshy, i just wanna thank you again for this program. It just saved me probably an hours worth of work or more messing around with rendering out maps from XSI from highres zbrush models, just doing some really simple stuff, but its sooo much faster than xsi.
Oh one thing that i noticed, there seems to be a limit to the smallest size map you can make... I was rendering out a 32x32 and a 64x64 and it defautled to 128, which means i lose a little bit of detail when downsizing.
Very nice MoP!!!!!!!! Is superüber model! I love dungeon & dragons online!
Hey! 2200 alphatris should be wiping your graphics card haha! Alpha sorting is slooooooooooooooooooow. Suggestion: try to separate parts with alpha in other OBJ if ya can.
And yep yep I think can change it to rotate around the mass center instead of the (0,0,0).
Hey btw I looked at the specular modulation shader you mentioned... I am using something like
The saturate is a [0,1] clamp... specMod.rgb is the specular modulation texture color, specMod.a is the specular power from the specular texture (16/256 if no alpha)... So the specular RGB texture should modulate well the light.
Have you tryed to low the light intensity, specular color and pixels in the texture or is working well now?
To Earth:
And yep yep Earth, min normal map is 128 and you're right... I am changing the supersampling by adaptive multisampling in the next version so it won't have to downsample... In fact, the supersampling as is implemented in the current version sux a few because requires tons and tons of memory and have the problem you mentioned... I'm changing it atm. Have the v3.5.2 almost finished ( and will use the weld thing more agressively as you suggested btw )
To Maya 7 users:
Mhwaaaaaaaaa! I've discovered a superbug loading OBJ files exported with Maya 7! Will be solved in the 3.5.2 asap!
Hehe, that model isn't actually from Dungeons and Dragons Online, but some of the other stuff on my site is (the suits of armour)
It's actually running fine with that alpha map on, 1280x1024, 6xAA ... yeah, I usually do try to separate off the files when working with just a few alphas on a big model, but this is all together and it's not a problem
And you're right about the specular colour and stuff, it's working perfectly... again, I'm just stupid and wasn't looking hard enough at it!
Edit: I'm an idiot, I had a question but then I read the help! Great document, I should read it more often and not ask silly questions
So I got reflection maps working correctly now, would it be possible to have them unaffected by the scene light? Actually, I guess that doesn't matter if you're going to add ambient cubemap lighting (which can use the same cubemap as the reflection map), since then the reflection will always be visible. Right now the reflections disappear as it gets darker, which kind of implies there is no "environment" (but like I say, ambient lighting will solve this).
Also is there a way to get "fresnel" (you know, this thing) shading on the reflections? Like if you look at something reflective in real life, as the angle gets more extreme in relation to the viewer, the reflection gets more intense?
They use this effect very well for car models in Project Gotham Racing, as you can sort of see here: http://www.xbox-360-pics.com/xbox-360-games/project-gotham-racing-3/screen7.jpg
Wee Xbox 360 is cool!
Yep yep, fresnel = more angle->more reflection. A coefficient is used too to simulate the material properties ( diamond, iron, ore, etc.. ) I'm adding fresnel to my TODO list, good idea. While, you can use the gloss texture to make the surface less reflectant ( rgb=modulation, .a=blend factor with the base texture )
And yep, cubemap diffuse lighting is incoming. The problem is that I can't find any diffuse cube maps in the Internet and I am too pathetic managing Photoshop to do one hahah Do you know any place where I could download some diffuse lighting cubemaps to test, please? ( in Debevec.org there are only brute light probes... I need to blur them or something... looks hard for a programmer and I don't wanna do other program to extract the luminance and PRT coeficients from it ><! )
Also looking for a free-and-good program to do some video-tutorials about how to use xNormal, but no luck
There's a free video capture tool for download there, I don't know how good it is though. I used to use a different one but I can't seem to find it anymore
If you want a quick testing cubemap, you could just apply a Gaussian Blur filter with a high value, on your example St Peter reflection map that you have in the "examples" folder of Xnormal, maybe?
Hmm, I know halflife2 used diffuse cubemaps for lighting ... maybe someone can extract one of their textures for testing.
Eric Chadwick might be a good person to ask, he knows about this stuff, I think.
I dont want to steal you away from this project, so this is'nt urgent, but would you be interested in paid contract work? It's more of a proof of concept, and most of the requirements are already handled in your renderer for this.
Replies
I just did another test, ignore the errors on ears and nose, thats just cage issues... Seems like im getting a lot of smoothing errors here, should i be manually triangulating my mesh before running it through this program?
I would try welding the horizontal forehead seam and move the eye UVs down to the bottom of the map, a bit more stretching in that area is much more preferable to having a big-ass UV seam there. See what happens after you do that and sort out the cage?
Also, sure to collapse all the meshes into one using the same material before to export as OBJ. Sure too the vertices and UVs are weld in the zones you have the seams.
Also caution because some non-Maya OBJ exporters really mess the vertex normals ( like 3DSMAX... make a cube.. export mesh with vertex normals and see the disaster editing the .obj with the notepad... All the vertex normals will be (0,0,-1) ! )
If you still have problems with smoothing try to manually triangulate the mesh ( Maya->Polygons->Triangulate or sometring like that ). And if still have problems then is my fault or a bug hehe
I don't like too much the 3DS/LWO formats because they don't export vertex normals accurately ( it only exports per-face smooth groups ). xNormal supports Lightwave 6.5 or above ( known as LWO2 ) format, not sure what kind of LWO exports Modo sorry.
Milkshape 3D (.ms3d) can export vertex normals very good as well as Softimage XSI ( dotXSI files ). You can try to export in these formats if you have problems too.
The normals are completely toast, it looks like the program is giving precedence to the innermost surface if there are multiple in range. For a comparison, with an ORB-generated normalmap the result looks like this:
The files are .objs generated with Blender, should I email them to you?
In theory this is what xNormal does:
Fire rays from the inner cage to the outter cage ( if cages are enabled ). Fartest hit is taken always. If rays fails hit then use closest hit. If this fails use lowpoly normal.
Are you using cages? If not, have you set a good outter and inner distance ( mesuring with a 3dsmax "tape" or something )? Are you using any "swizzle" coord to change model coordinate system? Are you using exported normals or averaging them? Is your model using more than one material by mesh? Do you see the "XXXXXX rays failed" after generating the normal map? Yep yep, it appears is taking closest hit for some motive ( see the nipples, cloth floating geometry is being ignored or something like that ), prolly because is missing some hits.
Ok too much questions... Send me the model ( lowpoly obj + highpoly obj + xml settings + .cag files ) if ya want and I will try to answer asap
This time I changed completely the ray heuristics. Now I am using a method that allows to forget forever the ray distances, so I disabled the cages functionality because were not needed ( more tests needed but I think cages and distances are history! )
Also changed the heightmap algorithm to be more accurate, specially at triangle edges.
Added the glow effect for emissive texture with a slider to control intensity and a checkbox to disable it. See a preview image:
Also put an option to hide lowpoly/highpoly meshes inside the viewer.
Solved a very bad crash rendering normal maps with multiple meshes.
Now it allows too to launch the viewer without lowpoly models loaded if you wanna see only the highpoly meshes as requested.
Added numerical values to some 3D viewer controls.
Now the viewer uses alpha sorting per triangle ( very accurate but can be slow sometimes so beware the # of alpha-texture polygons you put... ). Now the entire acid example is alpha-sorted ( eyes are semi-transparent and reflective )
Changed too that ugly green V button by a new aqua one ( thx MoP for the inspiration ). Hopefully in a few I will let you to use skins for xNormal.
The complete change list is in www.santyesprogramadorynografista.net/archives/xNormal_changes.txt
and you can download it as always in
www.santyesprogramadorynografista.net/projects.aspx and http://santyhammer.blogspot.com
Changed tons of things so I bet some error/bug is there waiting to assault you at some point
Will try answer you by Monday ( this weekend I wanna rest some )
Btw KDR, your Hitomi now should render OK because I used her to do the tests
Hope you like it!
Here's a screenshot for you with the new effect - it's cool!
Is there any way that I could make the effect less "pixelly"? It looks like it's using some sort of extra texture overlayed onto the screen, but it seems very low-res... is that a problem with my graphics card or a setting I could change? I think if the effect was smoother it'd be perfect.
Also, I haven't tested a lot to make sure of this, but does the Specular texture use colour, or is it just black and white? I've got a coloured Specular map on that screenshot, but it seems all the highlights are white no matter what colour the specular map is. Again this might be my fault, I'm not sure - I'll do some more tests
Good stuff, thanks!
Yep yep, I am using a little crappy shader atm for the glow ( and very low resolution.. 128x128 texture ). In the next version I will let you control the pixel range extent and the posteffect texture size for more control.
In theory, the specular texture uses RGB for specular modulation ( you can use too the light specular color for even more control ). If you pass it a texture with alpha the .A will be used to control the specular power ( shininess, variable per-pixel specular power.. 255 means very shiny, 0 means a biiiiig highlight )... I think I mentioned it in the docs, not sure. Specular can be a little weird too depending on the driver implementation due to a funciton called "POW"... Some cards allows to use something like X^2.7189 ( which is good ), but others just cap the decimals and provokes not very good specular btw. Also the Radeons 9XXX can't use floating point textures for the normalmap which can degrade a lot the specular too. Or perhaps is my fault because the xNormal shaders are passing the 100 HLSL lines lol!
If you can take two screenshots in a Radeon 9500 and in a GeForce6XXX/7XXXX/Radeon X1000 you will notice a brutal quality improvement due to floating point normalmap textures ( see specially the environment reflection quality too )
Interesting info too - I will try the same model and textures on a machine with a better graphics card and see how it looks
Cheers!
But I'm still getting artifacts:
As you can see some parts of the model have what seems like reflections of other parts of the model on them. Same issue I previously had with the occlusion maps. Since it doesn't seem to happen to you, is there something hardware reliant in the algorithm you're using? Or does the current algorithm simply not have a limit for the distance between lowpoly and highpoly surface?
If it helps my specs are: Athlon 64 3000+, 1024 MB RAM (dual channel), GeForce 6800, Windows 2000.
I think was good because just saw her from the front view... But yes, you're right... There is a problem when I see her from the right/left ... It appears the new heuristics failed 8( See the parts marked with a circle in normal map:
SORRY, will restore the cages algorithm asap then
I think the external cage at least is needed so the rays know when to stop and don't go on to other bits of highpoly geometry.
New version 3.5.1 patched is available.
Basically added back the cages and forgot the experimental crappy old method forever
I was trying to render Hitomi but I'm too lazy to set the cages in the hands... Noticed that model needs a lot of cage tweak ( specially at the inner one ) altought it can be almost ok using the new "Closest if ray fails" feature... But was great, that model teached a lot to me. Will try to setup it in a few and put some screenshots if I get it well but my artwork skills sux badly
Oh btw, I am thinking about making a video to teach how to setup well the cages.. Do you know any good and free program to capture a video from the screen pls?
As always you can download the new version at http://www.santyesprogramadorynografista.net/projects.aspx
The changes list is at http://www.santyesprogramadorynografista.net/archives/xNormal_changes.txt
I recommend you the new version because the v3.4.x were not using really the cages ( there was a bug and cages weren't loaded correctly ). Also the v3.5.0 ray algorithm was a little weird... So hope the v3.5.1 solves all.
Sorry for the mess!
Also the antialiasing thing seems to work now - I don't know if you did anything, maybe it was just me being stupid
Yep yep this is the normalmap is generating now after tweaking a few the cages:
Is good now but the hands tweaking was a bit hard hehe
I can't wait to see that sexy model finished KDR!
If all works now then I can start coding the new features for the v3.5.2 , like the multiple vertex selection using a rectangle area, the diffuse cubemap lighting ( low frequency lighting for PRT ) and the ASE support! ( and to start thinking in soft-area-penumbra-shadows and the new normalmap multisampling for the v3.6.0.. omg HEADACHE )
See ya soon!
Heres a pic:
and heres the files as well:
http://www.planetquake.com/polycount/cottages/crash/earthquake/devon.rar
edit: Oh btw I LOVE YOUR AMBOCC stuff, so fast!
Now, it looks like you are NOT checking the "Tangent space" in the Viewer 3D tab... It happens me a lot... Sure you have selected the SAME in the normal map generation tab and in the viewer 3D tab ( tab=the panels that appears when you press the right side buttons )... For example, if you generate the normal map in tangent space sure you ALSO checked the "tangent space" for the viewer... I think it could be that. To sure just don't use tangent space, use object space in BOTH.
See:
Here are the screens of what I get:
Used "Average CCW" smooth normals, object space ( again you need to generate normal map in object space AND then select object space TOO for the viewer.. notice object space is just not-to-check tangent space ) and tweaked the head fast using cages.
Here are my settings for Devon
Devon XML
Download the settings from there and change my texture and model paths by yours and all will be fine
And no, my AO sux.. In fact I am planning a new raycaster that uses the graphcics card and shadowmaps to accelerate the AO process a few!
Btw, I KNOW those globes are not the eyes... are the TITS!
Hey do you happen to have aim/icq/yahoo/etc or anything?
Ok so the turning on tangent in 3dviewer optiosn worked, but now i've got another problem. When you get close theres all kinds of artifacts, looks almost like theres unwelded edges here? Cant really tell if they are in your screenshot but it dosent look like it....
http://www.planetquake.com/polycount/cottages/crash/earthquake/devonprob03.jpg
Edit by MoP to fix giant image breaking formatting!
edited: YES, i see that too... When I turn the show tangent basis I see you must weld them better and sure UV's are welded too! See!
If are welded then try to export as dotXSI/LWO and not like OBJ to see if is an exporter problem
Also, don't use tangent space normal maps until you are 100% sure your vertices and UVs are well set, welded and pixel-snapped if possible... Prefer object space for undeformable objects and modelling/uv mapping process. Only use tangent space at the final, when you are previewing the final 3d game engine model... Tangent space is slower and can be conflictive due to the basis computation... If you can, use always the object space normal maps unless you need mirroring or deformable meshes.
Also, try to "relax" UVs on all your models... To see how much "unrelaxed" is your model texcoord use the checked.tga which is provided with xNormal as base texture ( in the xN_examples folder )
See:
As you notice, in those parts the UVs are very unrelaxed and non-countinuous mapped, which causes discontinuities in the tangent basis... You need to weld the vertex positions AND the UVs ( and use pixel-snap is possible)... Also, don't trust in exporters... Once you saved it to a file, edit the .OBJ or .XSI and see there are no degenerated faces , duplicated vertices or strange normals like (-0.000,-0.000,-0.0000) exported. I do a pass ( you can see it in the progress bar saying "Removing illegal geometry" ) to solve a few this but it could't work if the exporter does really bad job
My favourite format is the stanford PLY exported from Blender ( that's why I exported the acid in that format, because was the best vertex/face-count-optimized ). Then the OBJ exported from Maya and the 3DS exported from 3DSMAX 8. The dotXSI format from XSI 5.1 can be good too.
It can be a bug in xNormal too. Perhaps I should see back the import routines and tangent basis calculation.
edited: Yep, imported your model into Maya, relaxed UVs and welded verts and solved.
Yeah thats definately it, loaded .obj in max, all uv verts were unwelded, so i welded exported and now it works great.
Would it be posible to add in something that will auto weld verts in uvspace that are in exactly the same spot? Or within a tolerance....
[/ QUOTE ]
Not really.. think in a cube with every face mapped independently! What you mean by "same spot"?
I think there is only a way to sure model contains the correct geometry. Just sure you weld positions and UVs you want ( and always try to relax UV and pixelsnap while you map it ) + triangulate + remove degenerated faces + remove duplicate vertices + reset XForm in 3dsmax8 = the bibble of exporting haha!
Btw, anybody know a good and free video capturer? I wanna make some video tutorials of xNormal pls!
Would be the same thing as going into max, applying a uvunwrap, selecting all the verts and hitting weld from uvunwrap window with a really low tollerance.
Click for fullsize:
Also I got the alpha opacity maps working, as you can see! Thanks
Hey, and I just had another idea for something useful, hopefully not difficult to do:
- When pressing CTRL + right-mousebutton, at the moment the program will rotate the camera around the 0,0,0 point on the grid, yeah? Could you make it rotate around the centrepoint of the mesh, found by some method? For example maybe taking the average of vertex locations and setting that as the centre of the camera rotation.
Because at the moment, my guy's feet are at 0,0,0 - so when I rotate the camera with this CTRL method, it ends up looking at just his feet and legs instead of the whole model
Thanks!
Very nice MoP!!!!!!!! Is superüber model! I love dungeon & dragons online!
Hey! 2200 alphatris should be wiping your graphics card haha! Alpha sorting is slooooooooooooooooooow. Suggestion: try to separate parts with alpha in other OBJ if ya can.
And yep yep I think can change it to rotate around the mass center instead of the (0,0,0).
Hey btw I looked at the specular modulation shader you mentioned... I am using something like
<font class="small">Code:</font><hr /><pre>
col += specMod.rgb * lightSpecCol * saturate ( pow ( dotSpec, specMod.a * 256.0 ) );
</pre><hr />
The saturate is a [0,1] clamp... specMod.rgb is the specular modulation texture color, specMod.a is the specular power from the specular texture (16/256 if no alpha)... So the specular RGB texture should modulate well the light.
Have you tryed to low the light intensity, specular color and pixels in the texture or is working well now?
To Earth:
And yep yep Earth, min normal map is 128 and you're right... I am changing the supersampling by adaptive multisampling in the next version so it won't have to downsample... In fact, the supersampling as is implemented in the current version sux a few because requires tons and tons of memory and have the problem you mentioned... I'm changing it atm. Have the v3.5.2 almost finished ( and will use the weld thing more agressively as you suggested btw
To Maya 7 users:
Mhwaaaaaaaaa! I've discovered a superbug loading OBJ files exported with Maya 7! Will be solved in the 3.5.2 asap!
See ya soon!
It's actually running fine with that alpha map on, 1280x1024, 6xAA ... yeah, I usually do try to separate off the files when working with just a few alphas on a big model, but this is all together and it's not a problem
And you're right about the specular colour and stuff, it's working perfectly... again, I'm just stupid and wasn't looking hard enough at it!
Edit: I'm an idiot, I had a question but then I read the help! Great document, I should read it more often and not ask silly questions
So I got reflection maps working correctly now, would it be possible to have them unaffected by the scene light? Actually, I guess that doesn't matter if you're going to add ambient cubemap lighting (which can use the same cubemap as the reflection map), since then the reflection will always be visible. Right now the reflections disappear as it gets darker, which kind of implies there is no "environment" (but like I say, ambient lighting will solve this).
Also is there a way to get "fresnel" (you know, this thing) shading on the reflections? Like if you look at something reflective in real life, as the angle gets more extreme in relation to the viewer, the reflection gets more intense?
They use this effect very well for car models in Project Gotham Racing, as you can sort of see here: http://www.xbox-360-pics.com/xbox-360-games/project-gotham-racing-3/screen7.jpg
Yeah, just wondering about that
Great program Jogshy, you do awesome work!
Yep yep, fresnel = more angle->more reflection. A coefficient is used too to simulate the material properties ( diamond, iron, ore, etc.. ) I'm adding fresnel to my TODO list, good idea. While, you can use the gloss texture to make the surface less reflectant ( rgb=modulation, .a=blend factor with the base texture )
And yep, cubemap diffuse lighting is incoming. The problem is that I can't find any diffuse cube maps in the Internet and I am too pathetic managing Photoshop to do one hahah
Also looking for a free-and-good program to do some video-tutorials about how to use xNormal, but no luck
There's a free video capture tool for download there, I don't know how good it is though. I used to use a different one but I can't seem to find it anymore
If you want a quick testing cubemap, you could just apply a Gaussian Blur filter with a high value, on your example St Peter reflection map that you have in the "examples" folder of Xnormal, maybe?
Hmm, I know halflife2 used diffuse cubemaps for lighting ... maybe someone can extract one of their textures for testing.
Eric Chadwick might be a good person to ask, he knows about this stuff, I think.
It's a lot like camtasia in features and UI, but free.
let me know with a private message.