[ QUOTE ]
jogshy thats awesome man, you think you could make an option on ambient oclusion so that the settings could be tweaked to simulate cavity mapping ?
[/ QUOTE ]
I tryed but got a problem... cavity = small wrinkles, etc... and the AO bias value to avoid self-collision and floating point problems made it very hard. I think cavity requires a special treatment using some kind of image kernels/edge detection... well, with the new AA thrshold you could control this better, but won't be 100% perfect.
I've been trying to use it to check my textures as I'm working on them, but when I have the viewer in windowed mode, the cursor can't leave the xnormal window, even when alt+tabbed to another program. Any idea how to get around that? At the moment it means having to close the viewer, go back to photoshop, then run the viewer each time to check an update, instead of just alt+tab and clicking reload textures.
[ QUOTE ]
Any idea how to get around that? At the moment it means having to close the viewer, go back to photoshop, then run the viewer each time to check an update
[/ QUOTE ]
Have you tryed the ALT + ENTER to release/free the mouse cursor?
Added the feature to bake per-vertex-ao:
so now you can bake it using the GPU AO tool to an image or to vertex colors.
The 3d viewer was adapted to display per-vertex AO ( in highpoly and also lowpoly models )
And the best part... baked per-vertex-ao from the GPU tool can be used to project the highpoly AO into the lowpoly... without requiring the highpoly to be UV mapped.
You can choose this option to ignore the per-vertex-ao on the meshes you load:
in that way, the stored per-vertex ao from the GPU tool will be ignored and the traditional AO computation way will be used. I'm waiting on OpenGL 3.0 to simplify the process... currently cannot do it automatically due to the #$$%&&""@ old OGL design ( and more specifically the damm software mode fallback when something is not supported ) ... so you gonna need to play a bit with the options, sorry.
Now i'm gonna adapt the hxGrid distributed render to all the bucket rendering changes, etc... Once is completed gonna polish some details and release the Beta before the new year.
edited: Decided to delay the 3.14.0 to early January. Got some problems with the new VS2008 and libraries incompatibilities. I'm also improving memory usage using the Stanford's Lucy mesh (116M polys model) with 4k x 4k ao map to test.
- New render system using much less RAM than before.
- Adaptive antialiasing
- Realtime preview window
- Improved polycount support ( tested with the Stanford's meshes )
- Added per-vertex AO computation in the simple AO GPU tool.
and other minor upgrades and bug corrections.
The beta is only available in .EXE windows installer format by the moment, sorry ( no 7zipped one ).
[ QUOTE ]
The per-vertex AO is nice! It rendered the highpoly AO vertex colors to a lowpoly mesh with 2048 map in 15 secs!
[/ QUOTE ]
Btw, sure you use the FP16 or FP32 precission to fully-use the GPU. If you set it to CPU will use it only partially ( but sometimes is required if the graphics card cannot support floating point textures and filtering ). Unfortunally I cannot detect that condition due to the old OpenGL architecture until OGL3.0 spec is released.
Once the AO per vertex is baked using the simple AO GPU tool, xNormal will use it to compute the occlusion for the typical highppoly-lowpoly mechanism... If you set the "ignore per vertex AO" option on the corresponding highpoly slot then the per-vertex AO computed from the GPU AO tool won't be used and will take the "default" way to compute the AO.
I hope the Khronos group could release soon the OGL3.0 spec so I would be able to improve it a bit.
Btw, usually the NVIDIA's GPUs have a 1M polygon limit and the 16M for ATI ones.
its insanely fast. PERIOD. takes me 5 to 10 mins to render a full sample 2048x2048 amboc map with 300 samples etc. Way to go santi, couldnt be happier with Xnormal
I had a go and it wasn't rendering normal or AO maps correctly. Some parts of the normal map were just sort of washed out, like someone had taken a pen and randomly smeared the neutral blue around. The AO map (I did the simple AO thing first, then baked AO map) was also very washed out and the darkest parts were a mid grey.
On the plus side, I've now got obj meshes to work as cages
It is insanely fast indeed, just hoping I can sort out what's going wrong with me
EDIT: I just tried with turning off 'enable weight' and I get a proper AO map, but I still get the artifacting which seems to match the artifacting in the normal map. I've checked the cage in xnormal and it seems fine, and is also the same one I used in maya which worked fine. The parts that bake properly come out ver well, just this artifacting that's the problem.
EDIT 2: Just tried without using the cage and the artifacts disappeared (new ones now, but that is just from wrong ray distance). So the problem seems to be it doesn't like my cage, even though it encompasses the high poly without interescting it, and also worked fine in Maya.
ts insanely fast. PERIOD. takes me 5 to 10 mins to render a full sample 2048x2048 amboc map with 300 samples
[/ QUOTE ]
I hope that's the typical AO way to render... because with the simple GPU AO tool you should be able to bake that in seconds using the FP16 or FP32 precission ( unless yhe GPU does not support full acceleration and goes into OGL software mode )
Btw, notice you can use the simple AO gpu tool to compute the occlusion per-vertex into a SBM. Then, you can use that SBM in the typical AO highpoly-lowpoly way to reuse it and render much faster the occlusion map.
[ QUOTE ]
The AO map (I did the simple AO thing first, then baked AO map) was also very washed out and the darkest parts were a mid grey.
[/ QUOTE ]
Well, some tips for the simple AO GPU tool about that:
If you check the "enable weighting" option the AO will be modulated using the dot product of the AO sample direction and the pixel normal ( which gives you a smoother and very "white" result usually ).
On the other hand, if you uncheck the "enable weighing" you will get a darker and more pronounced result... Usually is too dark, that's why the "bright" option was added to make it lighter ( use bright 2.0 for example ).
[ QUOTE ]
EDIT: I just tried with turning off 'enable weight' and I get a proper AO map, but I still get the artifacting which seems to match the artifacting in the normal map. I've checked the cage in xnormal and it seems fine, and is also the same one I used in maya which worked fine. The parts that bake properly come out ver well, just this artifacting that's the problem.
[/ QUOTE ]
Perhaps you forgot to check the "use cage" on the lowpoly slot?
Also, when you render the AO map, try to play with the "limit ray distance" option. Check or uncheck it to see if helps. Usually uncheck it for outdoor scenes(like a terrain) and check it for characters to avoid extreme self occlusion(and sure the cage or uniform ray distance is well set)
To avoid artifacts increase the # of ray samples. Also sure you set the "adaptive interval" to a not-very-small value and also caution with the adaptive threshold. If you have doubts about the AO adaptive thing just set it to the same value than the # of ray samples and will be disabled ( for example... if you use 128 ray samples, setting the adaptive interval to 128 will disable the adaptive thing ). It basically works as follows:
Each "adaptive interval" looks at its AO contribution to the final value. If it's less than the "adaptive threshold" then stops. If it's greater or equal then continues gathering more AO samples.
Well, if you can post any screenshot or you want to send me the mesh file I could tell you more if ya want.
-On the preview/rendering window it would be nice to have the 'close' button at its usual up-right location! I keep looking for it Also the usual minimize/maximize buttons could be here.
-An 'open texture' button that simply loads the generated texture with the application it is associated with in windows would be sweet. I keep trying to doubleclick the previewed map to view it bigger :P
-You might want to rename the 'normal map' tab simply as 'maps'.
-Also the 'output file' field is confusing. It looks like an editable field, but it's not... Since it's not editable it might be more suited to make it grayed out so to speak. I guess the point was to be able to scroll the line for the complete address but it's easy to check by clicking the '...' button anyways.
-In the 3D viewer tab there should be an 'don't load high definition meshes' tickbox. At the moment I keep going back up the the high definition mesh tab to untick them so that they wont load in the viewer. I know there is an option to hide them from within the 3d view but it would be better to have that choice as an override before actually launching the viewer.
-When running the viewer windowed the mouse get stuck inside the window...
-Slider behave oddly - as soon as the pointer goes out of the slider range it losts its grab on the slider. Usually you want the user to still have control on the slider even if it gets out of the slider active space.
-In the viewer you could maybe make all the rightclick controls as leftclicks... and map scrollwheel for zoom :P
-On a vista64 intallation the program still goes into C/program Files(x86).
-In the texture loading window there should be a 'all supported files' option on top of the available image importers.
Thanks for the AO tips by the way! I was running into the same problems. Love the draw stars button!!
Great stuff Jogshy. And yeah I agree with all of Pior's suggestions, that stuff will save a lot of time and confusion!
Basically the more stuff you can make "intuitive" (for example having the close button in the usual place!) it will just speed up using the program, and generally make everyone's experiences a lot smoother and happier
-On the preview/rendering window it would be nice to have the 'close' button at its usual up-right location! I keep looking for it Also the usual minimize/maximize buttons could be here.
[/ QUOTE ]
Yep you're right but I had to disable them temporally due to a bug in the window resizing mechanism. Microsoft was informed some time ago but it seems they don't fix .NET 2.0 issues anymore because was marked as a deprecated API ( and I don't wanna use the 3.5 because requires massive changes and occupies too many Mbs ).
[ QUOTE ]
-An 'open texture' button that simply loads the generated texture with the application it is associated with in windows would be sweet. I keep trying to doubleclick the previewed map to view it bigger :P
[/ QUOTE ]
Well, the preview window is so small because if not the program uses too much time re-scaling the image. .NET GDI+ bitmap rendering is really slow and occupies too much physical memory.
On the other hand, a "open result file" option could make an "out of memory" for x 4k map if xNormal is still open. I cannot use my memory manager when using .NET bitmap controls.
But, don't worry, I have learned the lesson and i'm gonna solve all this in xn4.
[ QUOTE ]
-You might want to rename the 'normal map' tab simply as 'maps'.
[/ QUOTE ]
Gonna rename it to "Map options"
[ QUOTE ]
-Also the 'output file' field is confusing. It looks like an editable field, but it's not... Since it's not editable it might be more suited to make it grayed out so to speak. I guess the point was to be able to scroll the line for the complete address but it's easy to check by clicking the '...' button anyways.
[/ QUOTE ]
Yep, i'm trying to modify it so the user could enter or paste a path directly. Perhaps could change the background to white too.
[ QUOTE ]
-In the 3D viewer tab there should be an 'don't load high definition meshes' tickbox. At the moment I keep going back up the the high definition mesh tab to untick them so that they wont load in the viewer. I know there is an option to hide them from within the 3d view but it would be better to have that choice as an override before actually launching the viewer.
[/ QUOTE ]
Ok, gonna add a checkbox for that in the viewer options.
[ QUOTE ]
-When running the viewer windowed the mouse get stuck inside the window...
[/ QUOTE ]
ALT + ENTER can release/capture the mouse. I know it suxs but needed a way to switch the mouse mode for moving the camera, for browsing the viewer's UI, other to move/rescale the window and also to avoid some multimonitor problems. All this gonna dissapear with xn4 integrating the viewer into the main UI.
[ QUOTE ]
-Slider behave oddly - as soon as the pointer goes out of the slider range it losts its grab on the slider. Usually you want the user to still have control on the slider even if it gets out of the slider active space.
[/ QUOTE ]
Yep, the LUA scriptable controls are a bit odd sometimes. Unfortunally the app grew too much for the simple UI system I designed. Could use "focus" and tab indexing and other features but i'm not sure if it will worth the effort with xn4 comming.
[ QUOTE ]
-In the viewer you could maybe make all the rightclick controls as leftclicks... and map scrollwheel for zoom :P
[/ QUOTE ]
Heheh yep! I plan to make it mouse with 2 buttons-compatible... specially because some old Macs does not have a 3 button mouse. And yep, I could map the central wheel(if it's present) for zoom.
[ QUOTE ]
-On a vista64 intallation the program still goes into C/program Files(x86).
[/ QUOTE ]
Yep, that's because on x64 needs to install some x86 parts too... so the installer goes confused. I hope they fix that soon.
On Vista there are other problems due to UAC and registry incompatibilities ( for example, the installer cannot remove completely the xNormal entry from the startup menu ).
[ QUOTE ]
-In the texture loading window there should be a 'all supported files' option on top of the available image importers.
[/ QUOTE ]
Yep, i will change that. The problem with the current system is that user has to select the exact plugin ID to use... but I'm gonna add a method to select automatically a valid plugin to read the file ( something like a CanReadFile() method in the SDK ).
As usual, it's very nice to see how eager you are to add user requested features!!
About the image viewing size - I did not mean inside Xnormal but more like the following scenario : Lets say I have XNview or ACDSee installed (I actually don't, I use Fastone Maxview!), well I wish that when I am in the small preview window in Xnormal, doubleclicking the image would open this image in the image viewing program this kind of file format is associated too - just like clicking a windows thumb or icon really. That way it will fit everybody, without the need of image resizing routines inside Xnormal. I understand that these cost a lot of ressources.
Your dedication is quite something! Thanks a ton Jog. I might have some examples meshes to donate soon.
hey jogshy maybe some presets for ambient oclusion ( regular one ) another one to make stuff somesort of like cavity mapping , and another one for lowpoly amboc . yeah i know lame. Also whats the difference between cosine and uniform ?
[ QUOTE ]
Also whats the difference between cosine and uniform ?
[/ QUOTE ]
The point distribution used to generate the AO. It is supposed that the cosine one gives smoother results because is distributed against the surface normal... while the uniform generates the hemisphere points evenly.
In practice... I don't know and , sincerely, cannot see much difference ... but I promise you the code tries to make that hehehe
The "interior" AO ones are just experimental. They render the AO from inside the object instead from outside.
The "distance" one can be used to debug the cage placement ( if you see too much black or white colors) and also for other special effects... not sure how... somebody asked me to implement it and was easy ( I think it was for PRT )
So usually you will use the cosine distribution or the uniform one... The interior and distance ones are experimental.
Btw, I just uploaded a new small tutorial about how to use the simple GPU AO tool trick with the new per-vertex feature to accelerate the highpoly-lowpoly projective AO... and fear my Wink skeeelz!
Okay just tried the GPU AO tool, it rocks! 2 seconds for a 2048 AO map, thats what I like!
Couple suggestions regarding that tool :
-I wish one could load multiple meshes in the Simple AO Generator window, just like in the high definition meshes tab. Like, a highpoly arm and a highpoly head for instance. The program could then 'merge' the two objects together when creating the AOed SBM. It would make the process easier and this way the objects could occlude each other (maybe! I don't know if GPU AO work that way)
-Also at the moment to bake the actual map from verts to a texture, one needs to go back up in the highdef tab and make sure that ignore per vertex AO is unticked. It would make more sense (to me at least!) to simply have an option in the 'Normal Map' tab, in the Maps to render dropdown. Just like you have 'Normal map', 'Height map', 'Ambiant occlusion' aso you could add a line labelled 'GPU Ambiant ocllusion'. Or having GPU AO as a tickbox in the Ambiant Occlusion settings panel. (ticking this option would grey out all the CPU AO parameters, making the switch very obvious). Don't know which of these 3 methods is best tho.
Thanks again!
Edit - one more suggestion : you could maybe relabel the 'delete mesh' option in the highdef and lowdef tabs... It kindof feels like I delete the meshes files from the harddisk at the moment :P Something like 'unload' or 'remove mesh' maybe...
I wish one could load multiple meshes in the Simple AO Generator window, just like in the high definition meshes tab.
[/ QUOTE ]
Got that planned for 3.14.1. Currently I don't wanna modify too much the beta because the version could vary too much so I would need to release other beta to test.
[ QUOTE ]
It would make more sense (to me at least!) to simply have an option in the 'Normal Map' tab, in the Maps to render dropdown. Just like you have 'Normal map', 'Height map', 'Ambiant occlusion' aso you could add a line labelled 'GPU Ambiant ocllusion'. Or having GPU AO as a tickbox in the Ambiant Occlusion settings panel.
[/ QUOTE ]
I need to wait for OpenGL 3.0 to remove some options(like the precission one). I thought to make what you suggest but due to the old OpenGL 2 API design I need the user to choose some problematic parameters manually. If you don't select the params correctly a completely white or black map will be generated and the user won't know if that was because put some param bad of just because the graphics card does not support some required feature.
Once the OpenGL 3 spec is out I could integrate the GPU AO renderer into the default renderer as an option.. but, meanwhile, is too experimental and problematic... so I prefer to keep it as a sepparated tool by now.
[ QUOTE ]
you could maybe relabel the 'delete mesh' option in the highdef and lowdef tabs... It kindof feels like I delete the meshes files from the harddisk at the moment :P Something like 'unload' or 'remove mesh' maybe...
Modified the program to accept copy-pasted or manual file paths. Aligned the file textboxes in a way the file name is always visible ( not the path start ).
Also added the "don't load highpoly meshes" as Pior suggested.
And yep... you've seen well, acid_low.sia corresponds to the Silo mesh importer.
Good job Only problem I have with the "don't load highpoly meshes" is that it's yet another checkbox I will check, and forget about, and then curse and spit and wonder why the hell things won't work properly.
That's just me, though. If you were into bio-engineering I'm sure you could come up with a patch for -that-
[ QUOTE ]
Good job Only problem I have with the "don't load highpoly meshes" is that it's yet another checkbox I will check, and forget about, and then curse and spit and wonder why the hell things won't work properly.
[/ QUOTE ]
Yep, perhaps will be better to put a button to toggle all the visibility in the highpoly/lowpoly mesh list.
OK...i've taken the plung. i downloaded the newest beta. did a test. i got a normal map right away. however, it looks a little weird. also, i can't get the 3d viewer to show anything. thanks joshy for all your work...i really want to get this going. i'm so tired of doing it in max. here's my problem:
OK...fiddled around some and fixed that prob. however, i am still gettin problems getting something to show up in the 3d viewer. i am browsing through this thread and the pdf. i'd like to try the cage...but can't see anything.
THANKS AGAIN
here is a current prob i am curious about. the texture on the left was used with xnormal. the one on the right was used w/max(they are different models). the one using xnormal seems a bit pixelated when compared to the one using max. any ideas?
Jog : The idea behind having the 'hide highpoly mesh' tickbox in the 3d viewer panel is that it fits in the top to bottom workflow :
At the moment the user starts with the higher panel to load meshes...
then goes to a lower panel to genrate maps aso...
then the last panel at the very bottom for the viewer settings... launches the viewer...
and then bam, user needs to close the viewer and go all back up again and hide the highpoly meshes he forgot to untick.
It happened to me many times when demoing the Xnormal worflow in front of friends ... or AD :P
This is why I suggested a tickbox/button near the 'launch viewer' button in the last panel - to me it makes more sense because it actually reminds the viewer that he still needs to hide the highpoly.
here is a current prob i am curious about. the texture on the left was used with xnormal. the one on the right was used w/max(they are different models). the one using xnormal seems a bit pixelated when compared to the one using max. any ideas?
[/ QUOTE ]
Decrease AA threshold to 0.1 or 0.05
Also try to increase minAA to 1 and max AA to 4
Use the diagnostics to see if is skipping too many samples
THANKS jogshy. that totally helped. i'm getting a lot closer. i haven't used the cage yet...but i am getting smooth normals. they are not quite as smooth and crisp as what i get from max. maybe the cage is the key. my normals are still a little bit blurry. any tips anyone....anyone. i LOVE!!!! how xnormal handles dense meshes...love it. thanks again!!!
[/ QUOTE ]
Try to use cages always. Uniform ray distances are only good for very simple meshes like walls or spheres. It also allows you to control better not only the distance limitation but also the vertex normals's direction ( see the Poop's normal workflow tutorial ).
[ QUOTE ]
but i am getting smooth normals. they are not quite as smooth and crisp as what i get from max.
[/ QUOTE ]
Btw, caution with the max2obj exporter that max includes. It usually does not export well the vertex normals ( specially the hard edges , for example, from a cube ). Use the ASE, FBX or the xNormal SBM exporter better... and remember to ResetXForm before exporting.
Hey with the standard ambocc method i'm getting just black and white images, no detail whatsoever. Is there a setting somewhere i have to turn on to make this work correctly?
Memory usage and speed in general seems to be WAY improved. Great job! The realtime preview is awesome too.
[ QUOTE ]
Hey with the standard ambocc method i'm getting just black and white images, no detail whatsoever. Is there a setting somewhere i have to turn on to make this work correctly?
[/ QUOTE ]
Probably that's because you used the GPU AO tool and saved a failed/aborted/bad result per-vertex occlusion to the mesh you are using as highres one. Need to set the "Ignore per-vertex AO" option in the corresponding highpoly mesh list slot to use the typical 100% software AO computation.
EQ, i think you need to turn off Enable weighting in the AO settings, for some reason when this on you get a very washed out map, with it turned off you get what you would consider a standard AO map.
and by the way been testing this out a lot, and its absolutly awesome, i dont have to use turtle anymore!!
[ QUOTE ]
EQ, i think you need to turn off Enable weighting in the AO settings, for some reason when this on you get a very washed out map, with it turned off you get what you would consider a standard AO map.
[/ QUOTE ]
Yep, can be that too. Also sure you use a "bright" 1.0 if you enable weighing and near 2.0 if not.
hey jogshy...when i try to open the 3d viewer i get this:
(i have a geforce 7950 GT)
***edit, i guess this is because the open GL thingy right? i tried the direct 3d setting. it works, however...i have a dual monitor set up w/both monitors set up vertically. the 3d viewer is stretched across both screens. is this normal?
[ QUOTE ]
hey jogshy...when i try to open the 3d viewer i get this:
(i have a geforce 7950 GT)
***edit, i guess this is because the open GL thingy right?
[/ QUOTE ]
Yep, is an OpenGL's thing compiling shaders. Probably updating your Forceware drivers would solve it. If not, change the default graphics driver(in the Plugin Manager) to the Direct3D one.
[ QUOTE ]
i tried the direct 3d setting. it works, however...i have a dual monitor set up w/both monitors set up vertically. the 3d viewer is stretched across both screens. is this normal?
[/ QUOTE ]
Yep, well... I don't have two monitors to test/debug but I bet 2 monitors placed in vertical could cause some problems.
Sorry for the delay in the final version... but i'm waiting Microsoft to solve two nasty bugs:
1. The VS2008 redist is broken because tries to install files in the HD root dir ( which is write protected on some OSs like Vista ).
2. The D3D10CreateEffectXXXX functions and the offline compiler are severely bugged ( shader compiling errors, /Fh broken and bad shader padding length )
I seem to have the ambocc working now, after shuting off edge weighting, but the height map generator seems to not work so well. All it gives me is a flat black and white image, more like a mask than a height map. And there doesn't seem to be any options i can change here.
[ QUOTE ]
... the height map generator seems to not work so well. All it gives me is a flat black and white image, more like a mask than a height map. And there doesn't seem to be any options i can change here.
[/ QUOTE ]
Probably you need to set the min / max height in the heightmap's options. To know this distance you can use a 3dsmax's tape or set it to aprox the radius of the object.
Replies
jogshy thats awesome man, you think you could make an option on ambient oclusion so that the settings could be tweaked to simulate cavity mapping ?
[/ QUOTE ]
I tryed but got a problem... cavity = small wrinkles, etc... and the AO bias value to avoid self-collision and floating point problems made it very hard. I think cavity requires a special treatment using some kind of image kernels/edge detection... well, with the new AA thrshold you could control this better, but won't be 100% perfect.
I've been trying to use it to check my textures as I'm working on them, but when I have the viewer in windowed mode, the cursor can't leave the xnormal window, even when alt+tabbed to another program. Any idea how to get around that? At the moment it means having to close the viewer, go back to photoshop, then run the viewer each time to check an update, instead of just alt+tab and clicking reload textures.
Any idea how to get around that? At the moment it means having to close the viewer, go back to photoshop, then run the viewer each time to check an update
[/ QUOTE ]
Have you tryed the ALT + ENTER to release/free the mouse cursor?
Just tried and it works. Ta very much like
Added the feature to bake per-vertex-ao:
so now you can bake it using the GPU AO tool to an image or to vertex colors.
The 3d viewer was adapted to display per-vertex AO ( in highpoly and also lowpoly models )
And the best part... baked per-vertex-ao from the GPU tool can be used to project the highpoly AO into the lowpoly... without requiring the highpoly to be UV mapped.
You can choose this option to ignore the per-vertex-ao on the meshes you load:
in that way, the stored per-vertex ao from the GPU tool will be ignored and the traditional AO computation way will be used. I'm waiting on OpenGL 3.0 to simplify the process... currently cannot do it automatically due to the #$$%&&""@ old OGL design ( and more specifically the damm software mode fallback when something is not supported )
Now i'm gonna adapt the hxGrid distributed render to all the bucket rendering changes, etc... Once is completed gonna polish some details and release the Beta before the new year.
edited: Decided to delay the 3.14.0 to early January. Got some problems with the new VS2008 and libraries incompatibilities. I'm also improving memory usage using the Stanford's Lucy mesh (116M polys model) with 4k x 4k ao map to test.
- New render system using much less RAM than before.
- Adaptive antialiasing
- Realtime preview window
- Improved polycount support ( tested with the Stanford's meshes )
- Added per-vertex AO computation in the simple AO GPU tool.
and other minor upgrades and bug corrections.
The beta is only available in .EXE windows installer format by the moment, sorry ( no 7zipped one ).
Feel free to test and comment, please.
The per-vertex AO is nice! It rendered the highpoly AO vertex colors to a lowpoly mesh with 2048 map in 15 secs!
[/ QUOTE ]
Btw, sure you use the FP16 or FP32 precission to fully-use the GPU. If you set it to CPU will use it only partially ( but sometimes is required if the graphics card cannot support floating point textures and filtering ). Unfortunally I cannot detect that condition due to the old OpenGL architecture until OGL3.0 spec is released.
Once the AO per vertex is baked using the simple AO GPU tool, xNormal will use it to compute the occlusion for the typical highppoly-lowpoly mechanism... If you set the "ignore per vertex AO" option on the corresponding highpoly slot then the per-vertex AO computed from the GPU AO tool won't be used and will take the "default" way to compute the AO.
I hope the Khronos group could release soon the OGL3.0 spec so I would be able to improve it a bit.
Btw, usually the NVIDIA's GPUs have a 1M polygon limit and the 16M for ATI ones.
On the plus side, I've now got obj meshes to work as cages
It is insanely fast indeed, just hoping I can sort out what's going wrong with me
EDIT: I just tried with turning off 'enable weight' and I get a proper AO map, but I still get the artifacting which seems to match the artifacting in the normal map. I've checked the cage in xnormal and it seems fine, and is also the same one I used in maya which worked fine. The parts that bake properly come out ver well, just this artifacting that's the problem.
EDIT 2: Just tried without using the cage and the artifacts disappeared (new ones now, but that is just from wrong ray distance). So the problem seems to be it doesn't like my cage, even though it encompasses the high poly without interescting it, and also worked fine in Maya.
ts insanely fast. PERIOD. takes me 5 to 10 mins to render a full sample 2048x2048 amboc map with 300 samples
[/ QUOTE ]
I hope that's the typical AO way to render... because with the simple GPU AO tool you should be able to bake that in seconds using the FP16 or FP32 precission
Btw, notice you can use the simple AO gpu tool to compute the occlusion per-vertex into a SBM. Then, you can use that SBM in the typical AO highpoly-lowpoly way to reuse it and render much faster the occlusion map.
[ QUOTE ]
The AO map (I did the simple AO thing first, then baked AO map) was also very washed out and the darkest parts were a mid grey.
[/ QUOTE ]
Well, some tips for the simple AO GPU tool about that:
If you check the "enable weighting" option the AO will be modulated using the dot product of the AO sample direction and the pixel normal ( which gives you a smoother and very "white" result usually ).
On the other hand, if you uncheck the "enable weighing" you will get a darker and more pronounced result... Usually is too dark, that's why the "bright" option was added to make it lighter ( use bright 2.0 for example ).
[ QUOTE ]
EDIT: I just tried with turning off 'enable weight' and I get a proper AO map, but I still get the artifacting which seems to match the artifacting in the normal map. I've checked the cage in xnormal and it seems fine, and is also the same one I used in maya which worked fine. The parts that bake properly come out ver well, just this artifacting that's the problem.
[/ QUOTE ]
Perhaps you forgot to check the "use cage" on the lowpoly slot?
Also, when you render the AO map, try to play with the "limit ray distance" option. Check or uncheck it to see if helps. Usually uncheck it for outdoor scenes(like a terrain) and check it for characters to avoid extreme self occlusion(and sure the cage or uniform ray distance is well set)
To avoid artifacts increase the # of ray samples. Also sure you set the "adaptive interval" to a not-very-small value and also caution with the adaptive threshold. If you have doubts about the AO adaptive thing just set it to the same value than the # of ray samples and will be disabled ( for example... if you use 128 ray samples, setting the adaptive interval to 128 will disable the adaptive thing ). It basically works as follows:
Each "adaptive interval" looks at its AO contribution to the final value. If it's less than the "adaptive threshold" then stops. If it's greater or equal then continues gathering more AO samples.
Well, if you can post any screenshot or you want to send me the mesh file I could tell you more if ya want.
Hope it helped.
-On the preview/rendering window it would be nice to have the 'close' button at its usual up-right location! I keep looking for it
-An 'open texture' button that simply loads the generated texture with the application it is associated with in windows would be sweet. I keep trying to doubleclick the previewed map to view it bigger :P
-You might want to rename the 'normal map' tab simply as 'maps'.
-Also the 'output file' field is confusing. It looks like an editable field, but it's not... Since it's not editable it might be more suited to make it grayed out so to speak. I guess the point was to be able to scroll the line for the complete address but it's easy to check by clicking the '...' button anyways.
-In the 3D viewer tab there should be an 'don't load high definition meshes' tickbox. At the moment I keep going back up the the high definition mesh tab to untick them so that they wont load in the viewer. I know there is an option to hide them from within the 3d view but it would be better to have that choice as an override before actually launching the viewer.
-When running the viewer windowed the mouse get stuck inside the window...
-Slider behave oddly - as soon as the pointer goes out of the slider range it losts its grab on the slider. Usually you want the user to still have control on the slider even if it gets out of the slider active space.
-In the viewer you could maybe make all the rightclick controls as leftclicks... and map scrollwheel for zoom :P
-On a vista64 intallation the program still goes into C/program Files(x86).
-In the texture loading window there should be a 'all supported files' option on top of the available image importers.
Thanks for the AO tips by the way! I was running into the same problems. Love the draw stars button!!
Basically the more stuff you can make "intuitive" (for example having the close button in the usual place!) it will just speed up using the program, and generally make everyone's experiences a lot smoother and happier
Keep it up!
-On the preview/rendering window it would be nice to have the 'close' button at its usual up-right location! I keep looking for it
[/ QUOTE ]
Yep you're right but I had to disable them temporally due to a bug in the window resizing mechanism. Microsoft was informed some time ago but it seems they don't fix .NET 2.0 issues anymore because was marked as a deprecated API ( and I don't wanna use the 3.5 because requires massive changes and occupies too many Mbs ).
[ QUOTE ]
-An 'open texture' button that simply loads the generated texture with the application it is associated with in windows would be sweet. I keep trying to doubleclick the previewed map to view it bigger :P
[/ QUOTE ]
Well, the preview window is so small because if not the program uses too much time re-scaling the image. .NET GDI+ bitmap rendering is really slow and occupies too much physical memory.
On the other hand, a "open result file" option could make an "out of memory" for x 4k map if xNormal is still open. I cannot use my memory manager when using .NET bitmap controls.
But, don't worry, I have learned the lesson and i'm gonna solve all this in xn4.
[ QUOTE ]
-You might want to rename the 'normal map' tab simply as 'maps'.
[/ QUOTE ]
Gonna rename it to "Map options"
[ QUOTE ]
-Also the 'output file' field is confusing. It looks like an editable field, but it's not... Since it's not editable it might be more suited to make it grayed out so to speak. I guess the point was to be able to scroll the line for the complete address but it's easy to check by clicking the '...' button anyways.
[/ QUOTE ]
Yep, i'm trying to modify it so the user could enter or paste a path directly. Perhaps could change the background to white too.
[ QUOTE ]
-In the 3D viewer tab there should be an 'don't load high definition meshes' tickbox. At the moment I keep going back up the the high definition mesh tab to untick them so that they wont load in the viewer. I know there is an option to hide them from within the 3d view but it would be better to have that choice as an override before actually launching the viewer.
[/ QUOTE ]
Ok, gonna add a checkbox for that in the viewer options.
[ QUOTE ]
-When running the viewer windowed the mouse get stuck inside the window...
[/ QUOTE ]
ALT + ENTER can release/capture the mouse. I know it suxs but needed a way to switch the mouse mode for moving the camera, for browsing the viewer's UI, other to move/rescale the window and also to avoid some multimonitor problems. All this gonna dissapear with xn4 integrating the viewer into the main UI.
[ QUOTE ]
-Slider behave oddly - as soon as the pointer goes out of the slider range it losts its grab on the slider. Usually you want the user to still have control on the slider even if it gets out of the slider active space.
[/ QUOTE ]
Yep, the LUA scriptable controls are a bit odd sometimes. Unfortunally the app grew too much for the simple UI system I designed. Could use "focus" and tab indexing and other features but i'm not sure if it will worth the effort with xn4 comming.
[ QUOTE ]
-In the viewer you could maybe make all the rightclick controls as leftclicks... and map scrollwheel for zoom :P
[/ QUOTE ]
Heheh yep! I plan to make it mouse with 2 buttons-compatible... specially because some old Macs does not have a 3 button mouse. And yep, I could map the central wheel(if it's present) for zoom.
[ QUOTE ]
-On a vista64 intallation the program still goes into C/program Files(x86).
[/ QUOTE ]
Yep, that's because on x64 needs to install some x86 parts too... so the installer goes confused. I hope they fix that soon.
On Vista there are other problems due to UAC and registry incompatibilities ( for example, the installer cannot remove completely the xNormal entry from the startup menu ).
[ QUOTE ]
-In the texture loading window there should be a 'all supported files' option on top of the available image importers.
[/ QUOTE ]
Yep, i will change that. The problem with the current system is that user has to select the exact plugin ID to use... but I'm gonna add a method to select automatically a valid plugin to read the file ( something like a CanReadFile() method in the SDK ).
About the image viewing size - I did not mean inside Xnormal but more like the following scenario : Lets say I have XNview or ACDSee installed (I actually don't, I use Fastone Maxview!), well I wish that when I am in the small preview window in Xnormal, doubleclicking the image would open this image in the image viewing program this kind of file format is associated too - just like clicking a windows thumb or icon really. That way it will fit everybody, without the need of image resizing routines inside Xnormal. I understand that these cost a lot of ressources.
Your dedication is quite something! Thanks a ton Jog. I might have some examples meshes to donate soon.
thanks a bunch and happy new year
Also whats the difference between cosine and uniform ?
[/ QUOTE ]
The point distribution used to generate the AO. It is supposed that the cosine one gives smoother results because is distributed against the surface normal... while the uniform generates the hemisphere points evenly.
In practice... I don't know and , sincerely, cannot see much difference ... but I promise you the code tries to make that hehehe
The "interior" AO ones are just experimental. They render the AO from inside the object instead from outside.
The "distance" one can be used to debug the cage placement ( if you see too much black or white colors) and also for other special effects... not sure how... somebody asked me to implement it and was easy ( I think it was for PRT )
So usually you will use the cosine distribution or the uniform one... The interior and distance ones are experimental.
Btw, I just uploaded a new small tutorial about how to use the simple GPU AO tool trick with the new per-vertex feature to accelerate the highpoly-lowpoly projective AO... and fear my Wink skeeelz!
Couple suggestions regarding that tool :
-I wish one could load multiple meshes in the Simple AO Generator window, just like in the high definition meshes tab. Like, a highpoly arm and a highpoly head for instance. The program could then 'merge' the two objects together when creating the AOed SBM. It would make the process easier and this way the objects could occlude each other (maybe! I don't know if GPU AO work that way)
-Also at the moment to bake the actual map from verts to a texture, one needs to go back up in the highdef tab and make sure that ignore per vertex AO is unticked. It would make more sense (to me at least!) to simply have an option in the 'Normal Map' tab, in the Maps to render dropdown. Just like you have 'Normal map', 'Height map', 'Ambiant occlusion' aso you could add a line labelled 'GPU Ambiant ocllusion'. Or having GPU AO as a tickbox in the Ambiant Occlusion settings panel. (ticking this option would grey out all the CPU AO parameters, making the switch very obvious). Don't know which of these 3 methods is best tho.
Thanks again!
Edit - one more suggestion : you could maybe relabel the 'delete mesh' option in the highdef and lowdef tabs... It kindof feels like I delete the meshes files from the harddisk at the moment :P Something like 'unload' or 'remove mesh' maybe...
I wish one could load multiple meshes in the Simple AO Generator window, just like in the high definition meshes tab.
[/ QUOTE ]
Got that planned for 3.14.1. Currently I don't wanna modify too much the beta because the version could vary too much so I would need to release other beta to test.
[ QUOTE ]
It would make more sense (to me at least!) to simply have an option in the 'Normal Map' tab, in the Maps to render dropdown. Just like you have 'Normal map', 'Height map', 'Ambiant occlusion' aso you could add a line labelled 'GPU Ambiant ocllusion'. Or having GPU AO as a tickbox in the Ambiant Occlusion settings panel.
[/ QUOTE ]
I need to wait for OpenGL 3.0 to remove some options(like the precission one). I thought to make what you suggest but due to the old OpenGL 2 API design I need the user to choose some problematic parameters manually. If you don't select the params correctly a completely white or black map will be generated and the user won't know if that was because put some param bad of just because the graphics card does not support some required feature.
Once the OpenGL 3 spec is out I could integrate the GPU AO renderer into the default renderer as an option.. but, meanwhile, is too experimental and problematic... so I prefer to keep it as a sepparated tool by now.
[ QUOTE ]
you could maybe relabel the 'delete mesh' option in the highdef and lowdef tabs... It kindof feels like I delete the meshes files from the harddisk at the moment :P Something like 'unload' or 'remove mesh' maybe...
[/ QUOTE ]
Hehe, ok.
Modified the program to accept copy-pasted or manual file paths. Aligned the file textboxes in a way the file name is always visible ( not the path start ).
Also added the "don't load highpoly meshes" as Pior suggested.
And yep... you've seen well, acid_low.sia corresponds to the Silo mesh importer.
All this be available in the final version.
That's just me, though. If you were into bio-engineering I'm sure you could come up with a patch for -that-
Good job
[/ QUOTE ]
Yep, perhaps will be better to put a button to toggle all the visibility in the highpoly/lowpoly mesh list.
OK...fiddled around some and fixed that prob. however, i am still gettin problems getting something to show up in the 3d viewer. i am browsing through this thread and the pdf. i'd like to try the cage...but can't see anything.
THANKS AGAIN
here is a current prob i am curious about. the texture on the left was used with xnormal. the one on the right was used w/max(they are different models). the one using xnormal seems a bit pixelated when compared to the one using max. any ideas?
At the moment the user starts with the higher panel to load meshes...
then goes to a lower panel to genrate maps aso...
then the last panel at the very bottom for the viewer settings... launches the viewer...
and then bam, user needs to close the viewer and go all back up again and hide the highpoly meshes he forgot to untick.
It happened to me many times when demoing the Xnormal worflow in front of friends ... or AD :P
This is why I suggested a tickbox/button near the 'launch viewer' button in the last panel - to me it makes more sense because it actually reminds the viewer that he still needs to hide the highpoly.
Anyways! It's still minor.
here is a current prob i am curious about. the texture on the left was used with xnormal. the one on the right was used w/max(they are different models). the one using xnormal seems a bit pixelated when compared to the one using max. any ideas?
[/ QUOTE ]
Decrease AA threshold to 0.1 or 0.05
Also try to increase minAA to 1 and max AA to 4
Use the diagnostics to see if is skipping too many samples
i haven't used the cage yet...
[/ QUOTE ]
Try to use cages always. Uniform ray distances are only good for very simple meshes like walls or spheres. It also allows you to control better not only the distance limitation but also the vertex normals's direction ( see the Poop's normal workflow tutorial ).
[ QUOTE ]
but i am getting smooth normals. they are not quite as smooth and crisp as what i get from max.
[/ QUOTE ]
Btw, caution with the max2obj exporter that max includes. It usually does not export well the vertex normals ( specially the hard edges , for example, from a cube ). Use the ASE, FBX or the xNormal SBM exporter better... and remember to ResetXForm before exporting.
Memory usage and speed in general seems to be WAY improved. Great job! The realtime preview is awesome too.
Hey with the standard ambocc method i'm getting just black and white images, no detail whatsoever. Is there a setting somewhere i have to turn on to make this work correctly?
[/ QUOTE ]
Probably that's because you used the GPU AO tool and saved a failed/aborted/bad result per-vertex occlusion to the mesh you are using as highres one. Need to set the "Ignore per-vertex AO" option in the corresponding highpoly mesh list slot to use the typical 100% software AO computation.
and by the way been testing this out a lot, and its absolutly awesome, i dont have to use turtle anymore!!
EQ, i think you need to turn off Enable weighting in the AO settings, for some reason when this on you get a very washed out map, with it turned off you get what you would consider a standard AO map.
[/ QUOTE ]
Yep, can be that too. Also sure you use a "bright" 1.0 if you enable weighing and near 2.0 if not.
(i have a geforce 7950 GT)
***edit, i guess this is because the open GL thingy right? i tried the direct 3d setting. it works, however...i have a dual monitor set up w/both monitors set up vertically. the 3d viewer is stretched across both screens. is this normal?
hey jogshy...when i try to open the 3d viewer i get this:
(i have a geforce 7950 GT)
***edit, i guess this is because the open GL thingy right?
[/ QUOTE ]
Yep, is an OpenGL's thing compiling shaders. Probably updating your Forceware drivers would solve it. If not, change the default graphics driver(in the Plugin Manager) to the Direct3D one.
[ QUOTE ]
i tried the direct 3d setting. it works, however...i have a dual monitor set up w/both monitors set up vertically. the 3d viewer is stretched across both screens. is this normal?
[/ QUOTE ]
Yep, well... I don't have two monitors to test/debug but I bet 2 monitors placed in vertical could cause some problems.
1. The VS2008 redist is broken because tries to install files in the HD root dir ( which is write protected on some OSs like Vista ).
2. The D3D10CreateEffectXXXX functions and the offline compiler are severely bugged ( shader compiling errors, /Fh broken and bad shader padding length )
Hope you get the bugs resolved.
I got to say one thing though, the AO that the fast AO generates it the best I've ever seen in my life!
Enjoy it!
XSIFtk_6_0.dll not found
Xnormal still works after that message though.
... the height map generator seems to not work so well. All it gives me is a flat black and white image, more like a mask than a height map. And there doesn't seem to be any options i can change here.
[/ QUOTE ]
Probably you need to set the min / max height in the heightmap's options. To know this distance you can use a 3dsmax's tape or set it to aprox the radius of the object.
[ QUOTE ]
XSIFtk_6_0.dll not found
[/ QUOTE ]
Ouchies... gonna patch it asap, sorry.