Since he's doing all of this for free, doesn't anyone have an old wacom they can send Jogshy, even if only to 'lend'? Anyone who's upgraded to a bigger one and now has a spare one gathering dust?
Here's a preliminary result of the new trilight feature:
So well... it can simulate three lights with only one... but is a hack really. The "secondary" value controls the light coming from a side. The "tertiary" value controls light coming from the back side. Setting them to black annuls the trilight and sets the default lighting system.
The trilight will available for all the graphics drivers, not only for DX10.
Tweaking it a bit you can fake Lambert and rim lighting too.
Thanks for making it even easier to preview things properly, as well as making it easy to take decent screenshots with a minimum of work involved. I'm off to have a go at it right now.
Also, is there a way to change the size of the window if you're in windowed mode?
hey santi, i just wanted to ask you if you could make the cavity map a tad better , because right now it doesnt help much since it seems a blue channel shifted with values
here are some images of some cavity maps in action :
Right now i am using hacks to make a cavity map , but there are some obvious flaws wich require unecessary cleanup Also i might seem a noob asking this , but would be cool if you included a somesort of preview about the ambient oclusion when we tweak settings , like use a simple model and make it realtime dunno :S because that would allow me to make "experiments" without having to render the whole map again
Also maybe a button "clear all" to clear the lowpoly/highpoly tabs of previous models hehe...
yo johnny, check out how i get cavity maps from crazybump, its pretty easy, and they a bit more quality than the ones from zbrush, all you need is your normal map.
yeah i used that trick but sometimes some detail still gets non cavity values , maybe im crappy, but a bake method would be failproof hehehe , but i will keep using that one
( sometimes in crazybump the cav map has the tangent space map artifacts -lowpoly shading- etc )
[ QUOTE ]
i just wanted to ask you if you could make the cavity map a tad better
[/ QUOTE ]
Yep, the problem is the lack of technical information on cavity generation. For example, there is a lot of info about blur or convolution kernels but there is no source code, articles, equations or serious programming info about the cavity mechanics. Without that all I can do is just to try to approximate an image kernel to give you similar results to a reference result
WOW they both look great. I can't wait to get my hands on those. The contest ends April 7th and I am going to use Xnormal for my final Side question. I want to add more than 1 light for my scene. A darker moonlight and a light coming from a lantern. Any suggestions? I really want shadows from both.
I found the problem. I finally started getting detail after I unchecked both "Enable weighting" and "Limit ray distance". Phew, had to render it out a couple dozen times to figure it out, though.
- Added fast faked indirect lighting to the DX10 graphics driver. Added a new example ( the Cornell box ) to show this new feature.
- Improved the quality of the software raytracing graphics driver ( although is still too slow to be usable ). I have great secret plans for it however.
- Improved a bit the program's speed compiling it using SSE. Notice now a SSE-compatible CPU is required(Pentium 3/4, Intel Core/Core2, AthlonXP, AMD64, Via C3 Nehemiah/C7, etc... ).
- Corrected several bugs.
Btw, the indirect lighting only works well with closed scenes(like a room). Can be a bit slow sometimes. You can enable it setting the intensity slider greater than 0.015. To turn it off just set the intensity in range [0,0.015] ( I did that to save a check box ).
I added a blur pass to the SSAO as somebody suggested. Currently i'm using 64 samples. You can control the AO radius, AO bias and AO intensity. Let me know if you need more control over that.
hmm, I don't understand the "new" baking options. a few versions ago i could render ao, normal, color map in one pass. Now I just can choose one map at the "maps to render" tap
[ QUOTE ]
hmm, I don't understand the "new" baking options. a few versions ago i could render ao, normal, color map in one pass. Now I just can choose one map at the "maps to render" tap
[/ QUOTE ]
Yep, but I had to separate them to save memory.
[ QUOTE ]
btw you could add SSAO to openGL under XP as well, as GL always allowed reading depth textures by value.
[/ QUOTE ]
Yep, will be easy to port it once is well tuned.
Btw, i'm gonna release the 3.14.5 soon with gamma correction and a new tone map operator(I don't like the current one... is too unresponsive to the exposure)
Hey Jogshy, looking good as ever, impressive stuff man. I've been wanting to ask if you could implement something to help workflow. Me and quite a few others use a little trick when baking normals to prevent the raycasting sampling from unwanted bits of a complicated model without spending ages tweaking the cage. Basically, you "explode" both the highpoly and low poly meshes into chunks, like so :
This method works great, but if you're also baking ambient occlusion then the high poly model will no longer occlude itself correctly since there's loads of space between pieces. Would it be possible to generate AO on an "unexploded" high poly mesh, then explode both the high and low poly meshes automatically before baking normals etc.? The chunks of mesh would need to somehow be linked, either by naming convention (might be a bit fiddly), or through the UI. What do you think?
Theres a really easy fix to this, and i think what you're asking for is quite extreme, not something thats easily automated. I'll recap my workflow here.
After you have your highres, and lowres meshs:
Uv your lowres
Make a copy of lowres mesh
Explode copied version in low, and in highres
Save out orig version
Bake from exploded meshes
Load up the final lowres mesh in the "Simple AO tool", bake a texture the same resolution as your other textures and bam, composite this image in with the other ambocc texture, edit out the shadows on parts that need to move etc.
This could also be done with max etc if you dont like the quality of the simple ao tool for lowres meshes, i usually blur the map a little and spend a few seconds painting out errors. Also be sure to make a layer mask for parts of your mesh that would need to move, so it doesnt have ambocc on it.
Theres actually a few extra practical advantages to doing it this way as well:
1. When using floating geo, you'll often get ambocc artifacts that you need to paint out, if your mesh is exploded and you have seperate layers for high and low frequency ambocc its easier and quicker to paint out these errors that it is when you have the small shadows along with the large shadows both in the same texture.
2. Matching the exact silhouette of the lowpoly is actually a more desireable result than that of the highpoly.
Example: You have a 32 sided cylinder intersecting with some other shape, if you bake the ambocc directly from the highres you'll get a perfectly round shape. If you bake it from the lowres you'll get a shape that actually fits your model instead of just hurting the mesh by point out how jagged your lowres really is(via the contrast from the 12 sided guy casting a perfectly round shadow, not matching up correctly etc).
Heres a comp of what goes into my lightmaps for textures
1. AO from exploded
2. AO from lowres
3. 1+2 combined
4. Extra fluff, gradient baked down, NM thrown into crazy bump to create detail map, then overlayed, etc
5. Final diffuse
Me and quite a few others use a little trick when baking normals to prevent the raycasting sampling from unwanted bits of a complicated model without spending ages tweaking the cage. Basically, you "explode" both the highpoly and low poly meshes into chunks
....
What do you think?
I think is an interesting technique but cages are still needed. Cages not only control the ray's distance but also ray's direction, which is very critical for objects like cylinders. If you remove cages then it's needed a closest/furthest hit heuristic but complex meshes can give you incorrect results.
On the other hand exploding and non-self-occlusion-AO are incompatible. You need to work with shadow "layers", silhouettes, a lot of Photoshop blur and composite to get coherent occlusion results.
Also there is another problem with the exploding technique.... will be much slower to render than the cages one. The explanation is simple: imagine you have a character with some clothes. The ray test will stop when the ray, from the outside cage, hits the coat. With the exploding technique a lot of pixels in the base skin mesh need to be rendered... and won't be visible in the final model... so you will waste a lot of processing power.
So well... the exploding technique combined with simple-extruded-cages can be an interesting technique, specially for normal maps, but will be slower to render and you will need to perform some tweaks to composite the AO.
Why not bake your unexploded highpoly first, then transfer it to your game model later as a colour map?
Well that requires you to have uvs on your highres, or to have a really dense(evenly dense too!) mesh that will give enough quality from just vertex AO. And you want to explode the mesh in the first place so you don't have a bunch of normal map errors anyway. Also you run into the same problem that i explained here with that method:
2. Matching the exact silhouette of the lowpoly is actually a more desireable result than that of the highpoly.
Example: You have a 32 sided cylinder intersecting with some other shape, if you bake the ambocc directly from the highres you'll get a perfectly round shape. If you bake it from the lowres you'll get a shape that actually fits your model instead of just hurting the mesh by point out how jagged your lowres really is(via the contrast from the 12 sided guy casting a perfectly round shadow, not matching up correctly etc).
- DX10 gamma correction option ( fear the results if you enable it! You will discover that your textures have been never well adjusted! ). Probably you're gonna need some device like the Huey or the Eye-One Display 2 to get good calibrated results.
War, that's what I've been doing in Maya 7 all along, but as earthquake said it involves unwrapping the high res. Maya can't take nearly as high geo as Xnormal, so I'm looking for a way to work it in to my current workflow.
Earthquake, that's a nice method you've got there, I'll be giving that a shot for sure.
Jogshy, I never meant not to use cages, I still do in maya. My current workflow is :
1. Uv map highres, and bake AO to texture.
2. Bring in lowpoly (already UV mapped), explode both meshes by fixed amounts (units of 10). Save scene as characterName_baking
3. Tweak cages for best raycast, bake normal + colour (which is the highpoly AO).
4. Apply maps to unexploded low poly, in a seperate file. This way I preserve a scene ready for any rebaking that needs to be done with minimal rework.
BTW, cages in Maya don't seem to control ray direction, only maximum length. No tricks with cylinders available using it.
ok Im having a strange problem with my dom war piece,
when I load up the 3d viewer the hud is not visible and my mouse isnt visible either
it works fine when I just load my low poly but when I load both meshes it goes like this. Ive tried changing mesh scales but it doesnt seem to make any difference.
well I broke the high poly into 2 seperate meshes and then brought it in and it worked . So I dont know what that was about. I think my computers just run out of ram.
I prefer it when the cage doesn't skew the ray direction. Maya's is pretty nice, because you can just fuck with the cage however you want without worrying about point order, and screwing up the raycasts. Maybe that could be an option in xNormal? ie just use the cage as a ray-limiter and not the ray direction?
when I load up the 3d viewer the hud is not visible and my mouse isnt visible either
It seems you are running out or VRAM.
Try to enable the texture compression. Go to the plugin manager, select the DX9 graphics driver(the one you seem to use)... and uncheck the "Use texture compression" option.
On the other hand I see your VRAM usage too high ( 117Mb ). If you own a 128Mb graphics card gonna have problems with that. Try to reduce the size of the textures.
Btw, I see also your highpoly mehs is near 4M polys... not all the cards can manage that quantity. Usually for a 128Mb one the maximum number of tris/verts is 1M. Changing to OpenGL can help, because if a feature is not available by HW enters the emulation software mode ( but fear the speed ).
Try also to update your graphics card's drivers.
And, finally, try to use Vista with DX10... it has a new virtualized VRAM driver model that can help.
Try to enable the texture compression. Go to the plugin manager, select the DX9 graphics driver(the one you seem to use)... and uncheck the "Use texture compression" option.
On the other hand I see your VRAM usage too high ( 117Mb ). If you own a 128Mb graphics card gonna have problems with that. Try to reduce the size of the textures.
Btw, I see also your highpoly mehs is near 4M polys... not all the cards can manage that quantity. Usually for a 128Mb one the maximum number of tris/verts is 1M. Changing to OpenGL can help, because if a feature is not available by HW enters the emulation software mode ( but fear the speed ).
Try also to update your graphics card's drivers.
And, finally, try to use Vista with DX10... it has a new virtualized VRAM driver model that can help.
thanks for the reply, Im still having issues with this as youve seen in my dom war thread. I will try enabling texture compression but I dont have any textures yet. This is confusing because I have an 8800GT 512MB and 2GB ram so I just assumed this should be working. Ive tried playing with the size and turning use cage on and off and it isnt making any difference but maybe its all linked to this vram problem.
Edit: Ok I tried opengl and it now runs ok in the viewer but Im still getting the same issues when I click on bake so I will try reset xform in max on the low poly before export...with a new obj exporter that Im looking for now.
Hi, been having a problem baking AO today. I've not been using the simple AO tool (didn't like my meshes) so was just doing it the old fashioned way. The normal maps and texture bakes worked fine, but I get this result with the AO:
It's using a bucket size of 32, and I've tried different samplings but the same thing happens.
My computer is dual core with 2gb ram and an ati 1950xt using windows xp sp2.
I haven't tried it yet, but it does seem to be beneficial. For one, the AO calc for vert colors is done on the graphics card, which makes it insanely fast compared to raytraced AO output. The downside is that the lighting solution is only as accurate as the amount of verts in your highpoly. For an organic mesh that might not be an issue, but with rigid body models you might not always have enough to make it look decent.
I've noticed Mental Ray crashes when I try rendering to vertecies on meshes above 400k tris....
Looks like I'm running out of memory, didn't think it should be that demanding.
But like you say it works pretty well on organic meshes, and it's quite alot faster than rendering directly to texture.
I think I might have figured out what is causing the rays to fail on some of my models...Im getting alot of backface hits, does that mean I need to flip my normals on my whole mesh or something?
Replies
- TriLight. A simulation of three lights using just only one light.
- Fine detail improved options.
So well... it can simulate three lights with only one... but is a hack really. The "secondary" value controls the light coming from a side. The "tertiary" value controls light coming from the back side. Setting them to black annuls the trilight and sets the default lighting system.
The trilight will available for all the graphics drivers, not only for DX10.
Tweaking it a bit you can fake Lambert and rim lighting too.
Also, is there a way to change the size of the window if you're in windowed mode?
Also, is there a way to change the size of the window if you're in windowed mode?
[/ QUOTE ]
Window resizing is currently only allowed using the OGL graphics driver or the DX10 one. For DX9 currently is not supported.
here are some images of some cavity maps in action :
http://www.zbrushcentral.com/zbc/attachment.php?attachmentid=66829
also in polyboost features you can see a somesort of cavity map.
http://www.polyboost.com/
Right now i am using hacks to make a cavity map , but there are some obvious flaws wich require unecessary cleanup
Also maybe a button "clear all" to clear the lowpoly/highpoly tabs of previous models hehe...
keep rocking this man, awesome piece of work
http://boards.polycount.net/showflat.php?Cat=0&Number=275885&an=0&page=0#Post275885
its a pretty straight forward process, i dont know if it really needs to be added to xnormal, but you know another useful feature never hurts.
( sometimes in crazybump the cav map has the tangent space map artifacts -lowpoly shading- etc )
i just wanted to ask you if you could make the cavity map a tad better
[/ QUOTE ]
Yep, the problem is the lack of technical information on cavity generation. For example, there is a lot of info about blur or convolution kernels but there is no source code, articles, equations or serious programming info about the cavity mechanics. Without that all I can do is just to try to approximate an image kernel to give you similar results to a reference result
I got good results and could be implemented in the DX9/OGL drivers too because is very easy and fast.
Cornell box:
And two videos:
http://www.youtube.com/watch?v=oGultv4xSJk
http://www.youtube.com/watch?v=9ERXK-LrYmk
Indirect lighting won't produce shadows ( it was too slow for DX10.0.. DX10.1 is other history
I hope it could be finished(+SSAO + MTD) before the DW3.. btw... when ends the submission period?
Normal rendering:
With SSAO applied:
SSAO Only:
It's a very fast effect, totally computed on realtime.
edited: Here you can see a video with the final implementation:
http://www.youtube.com/watch?v=xQXfrMk1WE8
The 3.14.4 will be released soon... Next Monday probably.
However, every time I try to bake an AO map it comes out completely white, except for one or two dark spots.
Any idea what I could be doing wrong?
jogshy, the SSAO looks sweet. Is it possible to add a blur pass to it?
- Added SSAO to the DX10 graphics driver.
- Added fast faked indirect lighting to the DX10 graphics driver. Added a new example ( the Cornell box ) to show this new feature.
- Improved the quality of the software raytracing graphics driver ( although is still too slow to be usable ). I have great secret plans for it however.
- Improved a bit the program's speed compiling it using SSE. Notice now a SSE-compatible CPU is required(Pentium 3/4, Intel Core/Core2, AthlonXP, AMD64, Via C3 Nehemiah/C7, etc... ).
- Corrected several bugs.
Btw, the indirect lighting only works well with closed scenes(like a room). Can be a bit slow sometimes. You can enable it setting the intensity slider greater than 0.015. To turn it off just set the intensity in range [0,0.015] ( I did that to save a check box ).
I added a blur pass to the SSAO as somebody suggested. Currently i'm using 64 samples. You can control the AO radius, AO bias and AO intensity. Let me know if you need more control over that.
hmm, I don't understand the "new" baking options. a few versions ago i could render ao, normal, color map in one pass. Now I just can choose one map at the "maps to render" tap
[/ QUOTE ]
Yep, but I had to separate them to save memory.
[ QUOTE ]
btw you could add SSAO to openGL under XP as well, as GL always allowed reading depth textures by value.
[/ QUOTE ]
Yep, will be easy to port it once is well tuned.
(see also http://boards.polycount.net/showthread.php?t=48305&page=9 for a better example, Eric Chadwick's post)
This method works great, but if you're also baking ambient occlusion then the high poly model will no longer occlude itself correctly since there's loads of space between pieces. Would it be possible to generate AO on an "unexploded" high poly mesh, then explode both the high and low poly meshes automatically before baking normals etc.? The chunks of mesh would need to somehow be linked, either by naming convention (might be a bit fiddly), or through the UI. What do you think?
After you have your highres, and lowres meshs:
Uv your lowres
Make a copy of lowres mesh
Explode copied version in low, and in highres
Save out orig version
Bake from exploded meshes
Load up the final lowres mesh in the "Simple AO tool", bake a texture the same resolution as your other textures and bam, composite this image in with the other ambocc texture, edit out the shadows on parts that need to move etc.
This could also be done with max etc if you dont like the quality of the simple ao tool for lowres meshes, i usually blur the map a little and spend a few seconds painting out errors. Also be sure to make a layer mask for parts of your mesh that would need to move, so it doesnt have ambocc on it.
Theres actually a few extra practical advantages to doing it this way as well:
1. When using floating geo, you'll often get ambocc artifacts that you need to paint out, if your mesh is exploded and you have seperate layers for high and low frequency ambocc its easier and quicker to paint out these errors that it is when you have the small shadows along with the large shadows both in the same texture.
2. Matching the exact silhouette of the lowpoly is actually a more desireable result than that of the highpoly.
Example: You have a 32 sided cylinder intersecting with some other shape, if you bake the ambocc directly from the highres you'll get a perfectly round shape. If you bake it from the lowres you'll get a shape that actually fits your model instead of just hurting the mesh by point out how jagged your lowres really is(via the contrast from the 12 sided guy casting a perfectly round shadow, not matching up correctly etc).
Heres a comp of what goes into my lightmaps for textures
1. AO from exploded
2. AO from lowres
3. 1+2 combined
4. Extra fluff, gradient baked down, NM thrown into crazy bump to create detail map, then overlayed, etc
5. Final diffuse
On the other hand exploding and non-self-occlusion-AO are incompatible. You need to work with shadow "layers", silhouettes, a lot of Photoshop blur and composite to get coherent occlusion results.
Also there is another problem with the exploding technique.... will be much slower to render than the cages one. The explanation is simple: imagine you have a character with some clothes. The ray test will stop when the ray, from the outside cage, hits the coat. With the exploding technique a lot of pixels in the base skin mesh need to be rendered... and won't be visible in the final model... so you will waste a lot of processing power.
So well... the exploding technique combined with simple-extruded-cages can be an interesting technique, specially for normal maps, but will be slower to render and you will need to perform some tweaks to composite the AO.
Well that requires you to have uvs on your highres, or to have a really dense(evenly dense too!) mesh that will give enough quality from just vertex AO. And you want to explode the mesh in the first place so you don't have a bunch of normal map errors anyway. Also you run into the same problem that i explained here with that method:
- DX10 gamma correction option ( fear the results if you enable it! You will discover that your textures have been never well adjusted! ). Probably you're gonna need some device like the Huey or the Eye-One Display 2 to get good calibrated results.
- DX10 graphics driver's exposure more sensitive
- Corrected some bugs
Earthquake, that's a nice method you've got there, I'll be giving that a shot for sure.
Jogshy, I never meant not to use cages, I still do in maya. My current workflow is :
1. Uv map highres, and bake AO to texture.
2. Bring in lowpoly (already UV mapped), explode both meshes by fixed amounts (units of 10). Save scene as characterName_baking
3. Tweak cages for best raycast, bake normal + colour (which is the highpoly AO).
4. Apply maps to unexploded low poly, in a seperate file. This way I preserve a scene ready for any rebaking that needs to be done with minimal rework.
BTW, cages in Maya don't seem to control ray direction, only maximum length. No tricks with cylinders available using it.
when I load up the 3d viewer the hud is not visible and my mouse isnt visible either
it works fine when I just load my low poly but when I load both meshes it goes like this. Ive tried changing mesh scales but it doesnt seem to make any difference.
It seems you are running out or VRAM.
Try to enable the texture compression. Go to the plugin manager, select the DX9 graphics driver(the one you seem to use)... and uncheck the "Use texture compression" option.
On the other hand I see your VRAM usage too high ( 117Mb ). If you own a 128Mb graphics card gonna have problems with that. Try to reduce the size of the textures.
Btw, I see also your highpoly mehs is near 4M polys... not all the cards can manage that quantity. Usually for a 128Mb one the maximum number of tris/verts is 1M. Changing to OpenGL can help, because if a feature is not available by HW enters the emulation software mode ( but fear the speed ).
Try also to update your graphics card's drivers.
And, finally, try to use Vista with DX10... it has a new virtualized VRAM driver model that can help.
thanks for the reply, Im still having issues with this as youve seen in my dom war thread. I will try enabling texture compression but I dont have any textures yet. This is confusing because I have an 8800GT 512MB and 2GB ram so I just assumed this should be working. Ive tried playing with the size and turning use cage on and off and it isnt making any difference but maybe its all linked to this vram problem.
Edit: Ok I tried opengl and it now runs ok in the viewer but Im still getting the same issues when I click on bake so I will try reset xform in max on the low poly before export...with a new obj exporter that Im looking for now.
It's using a bucket size of 32, and I've tried different samplings but the same thing happens.
My computer is dual core with 2gb ram and an ati 1950xt using windows xp sp2.
Any ideas? Cheers.
- Render the occlusion to high-poly vertex color.
- Transferring that to my low-poly texture.
Anyone using that tech? Pros / cons , anyone?
Don't know if this is the right place to ask, just curious what you guys think.
Looks like I'm running out of memory, didn't think it should be that demanding.
But like you say it works pretty well on organic meshes, and it's quite alot faster than rendering directly to texture.