hey jogshy , this might sound a tad weird, but could you provide a link for an old version of xnormal ? its just that i really need to use xnormal and this current version is a tad unstabble since i have 4 gigs of ram and dual core and still cant render 2048x2048 with 4x anti alias and also cant render amboc , i know youll fix stuff but i really could use it ahahha.
anyway maybe you could add something like this : buttons with sizes like 512x512 , 1024x1024 2048x2048 , its kinda time wasting have to type it everytime ahahaha
And also , could you try to include an option to make the object space normal maps look close to the ones used from 3ds max ? because its handy to look at the texture work on it ahahah ( xnormal object space are diferent from 3ds max , maybe they are worldspace dunno im now confused )
also :
"no more damm outta memory mesages and you could render a 32k x 32k image with 32Mb of RAM or less)"
*keeps fingers crossed*
Also why not look into 3dsmax scanline method ? max is a piece of shit, but its rendering is pretty stable and quick
keep going jogshy will wait for next realese of xnormal
[ QUOTE ]
hey jogshy , this might sound a tad weird, but could you provide a link for an old version of xnormal ?
[/ QUOTE ]
I have only the 3.10.4 and 3.10.5. Gonna upload the 3.10.5 to a public sharing host and tell you the link.
[ QUOTE ]
xnormal object space are diferent from 3ds max , maybe they are worldspace dunno im now confused )
[/ QUOTE ]
Yep, I use standard OpenGL/Maya/XSI coordinate system while Max uses... a strange one.
Try to swizzle xNormal map using X+Z-Y+, i'm not 100% of the swizzle coords to use... but one combination should do the trick.
[ QUOTE ]
"no more damm outta memory mesages and you could render a 32k x 32k image with 32Mb of RAM or less)"
*keeps fingers crossed*
[/ QUOTE ]
Yep, i need to get rid of that asap... I got tired of the damm "outta memory" dialog spawn... I'm changing completely the render system to use very very few RAM ( gonna use bucket/tile rendering as MentalRay, with all its sampling options too 1/4,1/2,2,4,etc... adaptive sampling with customizable color error, box/gauss and jitter options ). Also gonna include something like the MR diagnostics.
I will save result directly to disk without wasting memory... and you will see all in the new preview window, bucket by bucket.
The GUI of xNormal has always been my biggest gripe. I love the feature set, but using it can somtimes be a bit of a chore. I hope a total revamp of the GUI is on the table for version 4, latest
But then again, maybe it's like when you enter a hair salon and you pick a hairdresser. You pick the one with the worst hair, because chances are she/he made the hair of the other ones' better looking hair.
That said, I've been shaving my head for the past 8 years, and haven't set my foot in a hair salon during that time :P
Every time I use the software the window's fixed size annoys. You've made the window so small that constant scrolling is needed to update the ray distance parameters in the file list.
...
It would be very nice to be able to select and edit several file fields simultaneously.
[/ QUOTE ]
Thanks for the feedback. Well, the XN3 UI was a bit messed because the app grew too much and run outta control.
You will be very pleased with xNormal 4.0 and its "standard" interface I'm not going to change xn 3.X UI by the moment... because gonna be deprecated by 2008 Q1
XN4 gonna use a standard app UI for linux and Windows ( and perhaps Mac if I could afford one... why are Macs so expensive? )
[ QUOTE ]
edit: Oh and not that it matters much, but knowing you you probably want to fix it: the right click menu in the file list says "mouse up" instead of "move up".
[/ QUOTE ]
Hahah, ok, fixed.
Btw, if you see any bad translation or string error you can change the .XML files named localization_XXXXXX.xml in the UI folder, change the string between "" and send me back the file... I translated all with the Google translator so I bet some phrases are, indeed, funny...
[ QUOTE ]
I hope a total revamp of the GUI is on the table for version 4, latest
[/ QUOTE ]
Yep, it is. Also portability, custom UI mofication + full scripting system + redo/undo system + integrated realtime 3D viewer in the UI + custom realtime shader + custom render shading. I'm planning also subdivision, a complete rendering system with GI/Final Gather and a 3D engine too.
I'm gonna make a post in my blog about XN4 soon... but first need to finish the 3.12.0 this week and then finish the 3.14.0(yep, 3.12+1.0 won't exist obviously) with the new tile/bucket rendering system.
cant wait man, also ill be translating the program to portuguese to make it more acessible to lazy portuguese ( i proly mentioned this , but it went down in the to-do list of things )
awesome, the new GPU AO works amazing and fits perfectly into our pipeline. We started texturing the high rez models and baking all maps from the high. The only sugesstion i see is that it would be cool to have the option to bake several "color" maps. since we paint the color, spec, incandescence, and now the AO on the high, being able to specify a few different textures to bake to the low would be awesome.
[ QUOTE ]
awesome, the new GPU AO works amazing and fits perfectly into our pipeline
[/ QUOTE ]
Good, but like somebody mentioned before, to UV-map highres models can be hard and slow... So gonna include an option to bake the AO into vertex colors too for the 3.14.0. If goes well, could extend it to the typical highres->lowres model projection system for the normal renderer.
Notice there is also a xNormal 3.12.0 Zipped(7z) package... do NOT download this by the moment(this is only for people who already installed the xNormal 3.12.0 Windows Installer(EXE) version so they will have the proper DirectX and VS2005 DLLs already installed on their system)
3) Run the xNormal 3.12.0.exe with administrator priviledges . That will install automatically the Visual Studio 2005 DLLs and DirectX if needed.
Also would be good idea to update your graphics drivers. Download the latests from, in your case, NVIDIA. I think the latest for your OS and card are the ForceWare 163.75 that you can find here:
Hey. I got another doozy and it doesn't make sense or it makes sense and there is a possible way out of it...
Ok, so I bake off a normal map and just looking at the map there are a ton of flaws, looks like it will be total crap. apply it in Maya and in a viewport with highquality mode it looks fine, totally awesome. I check it in the Xnormal Viewer and its fine as well.
Well that doesn't make any sense, it's showing the Normal map but its omitting obvious flaws... why? Someone explained it could be the output process, that it takes into account my lowpoly smooth groups and then spits out another normal map internally and that's what I am looking at. If that is what xnormal or maya is doing... is there anyway to get the corrected renormalized map?
If that isn't what it's doing, then what is going on here? Why can it be perfectly ok in maya, xnormal and not in the engine? What isn't this engine supporting or doing?
nothing, in maya you cant edit your invisible edges, when you export its probably just triangulating automatically not respecting the way its triangulated in maya, i triangulate the low rez model i bake before i export to xnormal. our engine usually does an okay job of exporting in our format, but if it looks messed up i go in and hand cut edges here and there to fix normal problems. this is a problem with your engine i think, try triangulating the model before you bake normals, also use that exact triangulated model to export in your engine.see if you still have the normal problems after that.
Nothing there is a flaw(in the map itself), actually quite the opposite that is exactly how it *should* look. You see the normal map has to compensate for the low poly model's smoothing.
Now as for as your in engine shot, there could be a number of factors that go into that. Most likely your engine is doing something different when it comes to reading/generating the normals/tangents/bitangents than what xnormal/maya do.
What engine are you using? I know UE3 has its own normals renderer and you should probablly use that if thats where the model is going.
Are we sure those aren't flaws? I've seen other hardbody normal maps and they usually dont have those strong gradients.
I'm also using UE3 and it's coming in all weird like that, which makes sense, because if there is such a difference in the colours on the normal map then it will render something there, but again maya and xnormal seem to adjust it based off smoothing groups, Ue3 doesn't.
A product of an ingame engine I suppose, but if maya/xnormal are infact renormalizing it on the fly for a render, there has to be a way we can bake that info off into the map.
Also I don't believe it's a triangulation thing since I auto tri'd it before taking it to Xnormal, so why wouldn't xnormal suffer the same flaws? Though I suppose triangulating it before baking would adjust the map, but figure you'd still have the tension in places just going the other way.
[ QUOTE ]
but again maya and xnormal seem to adjust it based off smoothing groups, Ue3 doesn't.
[/ QUOTE ]
I'm about 99.9% this isnt correct, eu3 may calculate its tangents/bitangents differently but it most certainly does take the normals of the low poly mesh into consideration.
Also, this could be something as simple as having your green channel inverted. The format maya/xnormal use is different from the format max/ue3 use, try inverting just the green channel in your normal and loading it up.
Sorry, let me clarify about the smooth group statement in Ue3.
UE3 does interpret what you do to the smooth groups. However what it seems maya is doing is calculating smooth groups, then re-rendering the normal map internally based off those smooth groups. That's why when you see a dent or something it doesn't render a dent, it's countered either by the smooth group calculation or renormalizing it based on the smooth group.
Also, I don't believe it's just a channel invertion, having objects bump up or down isn't really the case, it's how it's render the normal over the low poly.... but I'll give all this a shot tommorrow morning and post the results. Thanks!
As you can see now shows the realtime preview tile by tile(see the rectangle with diagonals)... and is consuming only 16Mb to render(btw is both image resolution and AA independent)
[/ QUOTE ]
In 2 weeks aprox. Wanna finish new bucket render system, new realtime preview dialog, adaptive sampling, modify the GPU AO tool to store per-vertex AO and to accelerate the AO highres-lowpoly projection with it. Also wanna add modo and silo mesh format support and textbox file drag'n'drop + manual edit.
Alright, so I gave the triangulation a shot before baking and importing. Even played around with how UE3 was importing the normal map, but all of it produced the same crappy results.
EDIT: Just adding this image as another example that better explains what is going on. When applying the normal map to a flat plane on a cube it renders those obvious oddities in the normal map I was talking about, but in the same scene on the LP mesh they aren't being rendered, same in Xnormal, so both programs are doing some sort of compensation based off the edge smoothness or something.
Not to be superstitious, but Maya and Xnormal are defiantly doing something additional to compensate for the oddities on the normal map that UE3 isn't. The question now is what is it doing and anyway we can replicate that for ue3. I'll post progress if I find out anywhere else, thanks.
okay i think earthquake was right, you defiantly need to invert your green channel. or when you bake your map in xnormal you need to swizzle the green channel.
Ape.of.Gods, how are you importing the mesh into UE3? The exporter that converts the mesh from Xnormal or Maya format into the UE3 format has to also convert the tangents/bitangents created during the normalmap bake. Without that info you'll get the weird shading like you're showing.
Just using the actorx static mesh exporter. With "Obey hard edges (convert to smoothing groups" checked (though unchecked it still produces a crappy result.
Ok, so with that in mind the way it's converting it to a .ase there is some info being lost there? Anyway around this or this just a crappy fact about unreal?
edit: Oh, and I tried inverting the green channel didn't do anything. What does swizzle do? Not familiar with the term. Thanks!
Ape , the normal map shows lightning errors , the engine is displaying them , maya high quality renderer aparently doesnt, max does the same in scanline renders. Also dunno why
Again, the "errors" you see are there to compensate specificly for the low poly model's normals. Of course it will look fucked when you put it on a plane.
If your exporter isnt sending out the exact same data that you have in maya/xnormal for this it will cause problems. UE3 is not magic and does infact need what you're seeing as errors. You wouldnt see something like that on a flat level texture or some or example because obviously it is *flat* and there is nothing to compensate for!
Also you may just not have enough geometry to support your normals in the lowres, on really sharp angles or messy geometry you're going to get problems, but if its working fine in xnormal you shouldnt have any issues.
Secondly, makes sense EarthQuake, so the issue would be in the format/information UE3 exports to... which really sucks because there isn't a lot of ways around this(..or is there?)
Also, tried epics generator a long time ago and it produces poo from what I remember and something I'd give a shot to if I figure out how to use it again, but if xnormal/maya can do it, what i need is to figure out how to get that info into the ase.
thanks again everyone.
EDIT: Ok used epic shTools and got a bunch of pixelated crap, so it's no good as far as that goes. Still going to work on the whole smoothgroup stuff as that seems to be the problem, maybe a bit more geo or something will do it. Also tried an object space map and it worked other then the fact that I cant use it for what I want now(moving around, lol)
I doubt the ASE format supports tangents & bitangents. I haven't used Epic's normalmapper, but I'd be hesitant to toss it out the window so quickly, as Epic artists obviously know what they're doing. And if/once you figure it out, you won't have to worry about tangents or extra geom or futzing with smoothing.
Have you tried inverting the green channel? one reason i think thats the problem is that it views fine in maya. maya and UE3 use different normal coordinates and xnormal does as well by default. so if it looks fine in maya then it is in no way going to look right in ue3 unless you invert the green channel.
jogshy, this thread has been going on so long I can't even remember if I've posted in it before. Just wanted to say thanks for the kick ass app and the frequent updates, it has become a program I use all the time.
Thanks, you rule, keep up the good work.
Yeah I tried to invert the green channel and didn't do it but make stuff not work well.
I'll have to see about using SHtools in max because I'm definetely not getting any sort of usable result out of Maya(though it shouldn't make a difference since it's a stand alone thing)
Yeah, it is getting to be a mighty thread, but I guess that's something to be proud of.
I'm trying to work out my workflow with xnormal again because I too would like to start getting into UE3 modding. I made a simple mesh the other day but had trouble getting the fine detail map to look right. In the end I just took it into photoshop, ran it through a normalmap filter, and flattened the regular normal map under it as an "overlay" layer. The results came out pretty good but made me want to ask, are there any plans to tweak the fine detail options? I can't seem to use it without loosing too much definition.
[ QUOTE ]
me want to ask, are there any plans to tweak the fine detail options? I can't seem to use it without loosing too much definition.
[/ QUOTE ]
Well, to be honest the fine detail option was a bit experimental and was only designed to add some kind of roughness or noise to the maps. Atm you can just control the color blend factor. Probably you can tweak it better in Photoshop. The fine detail can modify object space normal maps, which is hard to do just using PS.
To get better results use a detail map with the same size of the map being generated. For example, if you are generating a 512x512 normal map, use a 512x512 height map as detail map.
Currently there are no plans to modify it unless is something easy to do. For xn4 probably gonna use micro triangle displacement to add extra detail.
Aside from the blending object space maps thing, CrazyBump does a really good job of working with extra detail maps afaik. Most people are using that anyway so it might be worth it for you to look into it Caravaggio.
crazybump is just used for editing normal maps or generating from bump, but you can combine your base normals with some extra detail ones really easily
The new bucket render system is almost finished.
A screenshot of the options:
A picture showing the adaptive sampling diagnostics ( ala MR ) using 32x32 bucket size:
The new realtime preview window + 32x32 buckets being rendered ( on dual-core machine ):
I rendered a 8192x8192x16AA + dilation without problems with 256Mb of RAM installed on the test machine.
Now i'm working on the GPU AO tool improvements.
Btw, i'm removing the "alpha" map packing... alpha channels won't be used to store maps anymore ( old: normal map on RGB, heightmap on A... now: normal map RGB in a file, height map in other file ).
The 3.14.0 public beta will be available by early December.
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 ? thanks man REALLY looking forward to this !!!
Replies
anyway maybe you could add something like this : buttons with sizes like 512x512 , 1024x1024 2048x2048 , its kinda time wasting have to type it everytime ahahaha
And also , could you try to include an option to make the object space normal maps look close to the ones used from 3ds max ? because its handy to look at the texture work on it ahahah
also :
"no more damm outta memory mesages and you could render a 32k x 32k image with 32Mb of RAM or less)"
*keeps fingers crossed*
Also why not look into 3dsmax scanline method ? max is a piece of shit, but its rendering is pretty stable and quick
keep going jogshy will wait for next realese of xnormal
hey jogshy , this might sound a tad weird, but could you provide a link for an old version of xnormal ?
[/ QUOTE ]
I have only the 3.10.4 and 3.10.5. Gonna upload the 3.10.5 to a public sharing host and tell you the link.
[ QUOTE ]
xnormal object space are diferent from 3ds max , maybe they are worldspace dunno im now confused )
[/ QUOTE ]
Yep, I use standard OpenGL/Maya/XSI coordinate system while Max uses... a strange one.
Try to swizzle xNormal map using X+Z-Y+, i'm not 100% of the swizzle coords to use... but one combination should do the trick.
[ QUOTE ]
"no more damm outta memory mesages and you could render a 32k x 32k image with 32Mb of RAM or less)"
*keeps fingers crossed*
[/ QUOTE ]
Yep, i need to get rid of that asap... I got tired of the damm "outta memory" dialog spawn... I'm changing completely the render system to use very very few RAM ( gonna use bucket/tile rendering as MentalRay, with all its sampling options too 1/4,1/2,2,4,etc... adaptive sampling with customizable color error, box/gauss and jitter options ). Also gonna include something like the MR diagnostics.
I will save result directly to disk without wasting memory... and you will see all in the new preview window, bucket by bucket.
But then again, maybe it's like when you enter a hair salon and you pick a hairdresser. You pick the one with the worst hair, because chances are she/he made the hair of the other ones' better looking hair.
That said, I've been shaving my head for the past 8 years, and haven't set my foot in a hair salon during that time :P
Every time I use the software the window's fixed size annoys. You've made the window so small that constant scrolling is needed to update the ray distance parameters in the file list.
...
It would be very nice to be able to select and edit several file fields simultaneously.
[/ QUOTE ]
Thanks for the feedback. Well, the XN3 UI was a bit messed because the app grew too much and run outta control.
You will be very pleased with xNormal 4.0 and its "standard" interface
XN4 gonna use a standard app UI for linux and Windows ( and perhaps Mac if I could afford one... why are Macs so expensive? )
[ QUOTE ]
edit: Oh and not that it matters much, but knowing you you probably want to fix it: the right click menu in the file list says "mouse up" instead of "move up".
[/ QUOTE ]
Hahah, ok, fixed.
Btw, if you see any bad translation or string error you can change the .XML files named localization_XXXXXX.xml in the UI folder, change the string between "" and send me back the file... I translated all with the Google translator so I bet some phrases are, indeed, funny...
[ QUOTE ]
I hope a total revamp of the GUI is on the table for version 4, latest
[/ QUOTE ]
Yep, it is. Also portability, custom UI mofication + full scripting system + redo/undo system + integrated realtime 3D viewer in the UI + custom realtime shader + custom render shading. I'm planning also subdivision, a complete rendering system with GI/Final Gather and a 3D engine too.
I'm gonna make a post in my blog about XN4 soon... but first need to finish the 3.12.0 this week and then finish the 3.14.0(yep, 3.12+1.0 won't exist obviously) with the new tile/bucket rendering system.
Hehe, long live XML. I'd translate it to Swedish, but I get the impression Swedes today know English better than Swedish..
the gpu AO is brilliant!
awesome, the new GPU AO works amazing and fits perfectly into our pipeline
[/ QUOTE ]
Good, but like somebody mentioned before, to UV-map highres models can be hard and slow... So gonna include an option to bake the AO into vertex colors too for the 3.14.0. If goes well, could extend it to the typical highres->lowres model projection system for the normal renderer.
So far I've only been using transfers.
Anyone has the current updated link where I may try out this wonderful utility?
[/ QUOTE ]
http://www.xnormal.net/Downloads.aspx
Also uploaded it into
http://www.megaupload.com/?d=OWBZKYF9
Geeforce 8800 GTS
AMD Athlon 64 Dual Core Processor 3800=
2GB RAM
Windows XP 32 bit
Direct X 9
Do I need to install any new display drivers and if I do...what should a I do first to install it properly?
(Heard some horror stories about people's video being borked)
Edit: Ok, It works now, somehow the normals of my lowpoly got screwed up...
Geforce 8800 GTS
AMD Athlon 64 Dual Core Processor 3800=
2GB RAM
Windows XP 32 bit
Direct X 9
Do I need to install any new display drivers and if I do...what should a I do first to install it properly?
[/ QUOTE ]
Need to do:
1) Download and install .NET framework 2.0 for x86 ( with administrator priviledges). Get it at http://www.microsoft.com/downloads/detai...;displaylang=en
2) Download the xNormal 3.12.0 Windows installer(EXE) from http://www.xnormal.net/Downloads.aspx
Notice there is also a xNormal 3.12.0 Zipped(7z) package... do NOT download this by the moment(this is only for people who already installed the xNormal 3.12.0 Windows Installer(EXE) version so they will have the proper DirectX and VS2005 DLLs already installed on their system)
3) Run the xNormal 3.12.0.exe with administrator priviledges . That will install automatically the Visual Studio 2005 DLLs and DirectX if needed.
Also would be good idea to update your graphics drivers. Download the latests from, in your case, NVIDIA. I think the latest for your OS and card are the ForceWare 163.75 that you can find here:
http://www.nvidia.com/object/winxp_163.75.html
Ok, so I bake off a normal map and just looking at the map there are a ton of flaws, looks like it will be total crap. apply it in Maya and in a viewport with highquality mode it looks fine, totally awesome. I check it in the Xnormal Viewer and its fine as well.
Well that doesn't make any sense, it's showing the Normal map but its omitting obvious flaws... why? Someone explained it could be the output process, that it takes into account my lowpoly smooth groups and then spits out another normal map internally and that's what I am looking at. If that is what xnormal or maya is doing... is there anyway to get the corrected renormalized map?
If that isn't what it's doing, then what is going on here? Why can it be perfectly ok in maya, xnormal and not in the engine? What isn't this engine supporting or doing?
Can anyone explain? Thank you.
Now as for as your in engine shot, there could be a number of factors that go into that. Most likely your engine is doing something different when it comes to reading/generating the normals/tangents/bitangents than what xnormal/maya do.
What engine are you using? I know UE3 has its own normals renderer and you should probablly use that if thats where the model is going.
Yeah or its simply a triangulation problem.
I'm also using UE3 and it's coming in all weird like that, which makes sense, because if there is such a difference in the colours on the normal map then it will render something there, but again maya and xnormal seem to adjust it based off smoothing groups, Ue3 doesn't.
A product of an ingame engine I suppose, but if maya/xnormal are infact renormalizing it on the fly for a render, there has to be a way we can bake that info off into the map.
Also I don't believe it's a triangulation thing since I auto tri'd it before taking it to Xnormal, so why wouldn't xnormal suffer the same flaws? Though I suppose triangulating it before baking would adjust the map, but figure you'd still have the tension in places just going the other way.
Also, what are invisible edges?
but again maya and xnormal seem to adjust it based off smoothing groups, Ue3 doesn't.
[/ QUOTE ]
I'm about 99.9% this isnt correct, eu3 may calculate its tangents/bitangents differently but it most certainly does take the normals of the low poly mesh into consideration.
UE3 does interpret what you do to the smooth groups. However what it seems maya is doing is calculating smooth groups, then re-rendering the normal map internally based off those smooth groups. That's why when you see a dent or something it doesn't render a dent, it's countered either by the smooth group calculation or renormalizing it based on the smooth group.
Also, I don't believe it's just a channel invertion, having objects bump up or down isn't really the case, it's how it's render the normal over the low poly.... but I'll give all this a shot tommorrow morning and post the results. Thanks!
As you can see now shows the realtime preview tile by tile(see the rectangle with diagonals)... and is consuming only 16Mb to render(btw is both image resolution and AA independent)
when will it be available ?
[/ QUOTE ]
In 2 weeks aprox. Wanna finish new bucket render system, new realtime preview dialog, adaptive sampling, modify the GPU AO tool to store per-vertex AO and to accelerate the AO highres-lowpoly projection with it. Also wanna add modo and silo mesh format support and textbox file drag'n'drop + manual edit.
EDIT: Just adding this image as another example that better explains what is going on. When applying the normal map to a flat plane on a cube it renders those obvious oddities in the normal map I was talking about, but in the same scene on the LP mesh they aren't being rendered, same in Xnormal, so both programs are doing some sort of compensation based off the edge smoothness or something.
Not to be superstitious, but Maya and Xnormal are defiantly doing something additional to compensate for the oddities on the normal map that UE3 isn't. The question now is what is it doing and anyway we can replicate that for ue3. I'll post progress if I find out anywhere else, thanks.
Ok, so with that in mind the way it's converting it to a .ase there is some info being lost there? Anyway around this or this just a crappy fact about unreal?
edit: Oh, and I tried inverting the green channel didn't do anything. What does swizzle do? Not familiar with the term. Thanks!
If your exporter isnt sending out the exact same data that you have in maya/xnormal for this it will cause problems. UE3 is not magic and does infact need what you're seeing as errors. You wouldnt see something like that on a flat level texture or some or example because obviously it is *flat* and there is nothing to compensate for!
Secondly, makes sense EarthQuake, so the issue would be in the format/information UE3 exports to... which really sucks because there isn't a lot of ways around this(..or is there?)
Also, tried epics generator a long time ago and it produces poo from what I remember and something I'd give a shot to if I figure out how to use it again, but if xnormal/maya can do it, what i need is to figure out how to get that info into the ase.
thanks again everyone.
EDIT: Ok used epic shTools and got a bunch of pixelated crap, so it's no good as far as that goes. Still going to work on the whole smoothgroup stuff as that seems to be the problem, maybe a bit more geo or something will do it. Also tried an object space map and it worked other then the fact that I cant use it for what I want now(moving around, lol)
Thanks, you rule, keep up the good work.
jogshy, this thread has been going on so long I can't even remember if I've posted in it before.
[/ QUOTE ]
Don't worry, next year you will have a xn4 where to write hehe
Oh btw, I think for UE3 you need, indeed, to invert green channel ( use swizzle X+Y-Z+ if you generated the normal map in xnormal ).
I'll have to see about using SHtools in max because I'm definetely not getting any sort of usable result out of Maya(though it shouldn't make a difference since it's a stand alone thing)
I'm trying to work out my workflow with xnormal again because I too would like to start getting into UE3 modding. I made a simple mesh the other day but had trouble getting the fine detail map to look right. In the end I just took it into photoshop, ran it through a normalmap filter, and flattened the regular normal map under it as an "overlay" layer. The results came out pretty good but made me want to ask, are there any plans to tweak the fine detail options? I can't seem to use it without loosing too much definition.
Thanks for the great program again.
me want to ask, are there any plans to tweak the fine detail options? I can't seem to use it without loosing too much definition.
[/ QUOTE ]
Well, to be honest the fine detail option was a bit experimental and was only designed to add some kind of roughness or noise to the maps. Atm you can just control the color blend factor. Probably you can tweak it better in Photoshop. The fine detail can modify object space normal maps, which is hard to do just using PS.
To get better results use a detail map with the same size of the map being generated. For example, if you are generating a 512x512 normal map, use a 512x512 height map as detail map.
Currently there are no plans to modify it unless is something easy to do. For xn4 probably gonna use micro triangle displacement to add extra detail.
Does crazy bump make normal maps from models though? The site is so spartan....
A screenshot of the options:
A picture showing the adaptive sampling diagnostics ( ala MR ) using 32x32 bucket size:
The new realtime preview window + 32x32 buckets being rendered ( on dual-core machine ):
I rendered a 8192x8192x16AA + dilation without problems with 256Mb of RAM installed on the test machine.
Now i'm working on the GPU AO tool improvements.
Btw, i'm removing the "alpha" map packing... alpha channels won't be used to store maps anymore ( old: normal map on RGB, heightmap on A... now: normal map RGB in a file, height map in other file ).
The 3.14.0 public beta will be available by early December.