Yes EarthQuake I totally understand what you say, also doing double bakes for more accurate details is quite interesting - I plan to test it on my current work asset.
Working directly form modo is limited, fortunately I will soon finish upgrading my .obj exporter from modo.
It will support apply morph, automatic cage, resize, smoothgroups and vertex normals ... all in commandline format so it can be farther automated
no both values are worng, 127,127,255 is the best!
Just to clarify, because the range is 0-255, 127 is the exact middle, not 128(if the range was 1-256)
or is it 127.5? Fuck, Santi, we need more range in our pixels here buddy.
off topic here, but chai: you should make a modo script that sets all of your uv boarders to be hard edged, if you're doing all this smoothing group stuff there.
I see what you're saying, but 0-255 is 256 values, which makes 128 the middle.
I always end up with visible seams when I use 127 as the mid value and overlaying multiple normal maps onto each other, which is not so when I use 128, whether it's correct or not.
jeffrussell: well, you have [0,255] mapping to [-1,1] right
jeffrussell: so the math to expand is this:
jeffrussell: 2*(tex/255) - 1
jeffrussell: so there's no integer in there that gives you exactly 0
jeffrussell: you can try both 127 and 128
jeffrussell: 127 slightly under 0, 128 slightly over
Its interesting that you get errors with 127, maybe you're doing something incorrectly when overlaying them(like not clamping the levels to 127 in blue)? Both 127 and 128 should be *equally* wrong, from what its been explained to me. Also when i render a flat plane onto itself i get a 127,127,255 map, atleast from xn. I wonder if this is an engine/shade specific thing.
Ahhh, I didn't know the math behind it didn't allow for exactly 0.
It's been a while since I've tried using the 127, chances are I just wasn't good at editing normal maps back then.
Just out of curiosity, what software do you view your models in?
I'm using Maya, which the 128 problem may have something to do with how it reads the data.
I've used various apps and never had a problem with the 127 thing, really the difference should be so minute between 127 and 128 that it would never be noticeable unless something else was wrong, but who knows. I am not officially a scientist.
A quick insignificant thing:
The default background color for normal maps in the latest release is 126, 126, 255.
Oooopz! I'll fix it for the final 3.16.12 version.
As jeff said, neither 127 nor 128 is correct.
the correct is 127.5... but that's impossible for a RGB8 integer format...
I've seen usually a 127,127,255 value in other programs.
Do you know any other bug? I plan to release the final 3.16.12 the next week.
i just had the ultimate error in Xnormal.
i wanted to set it to german language (wich was a big mistake anyways because this is not german...its googiberrish... well and now everything is set up just wrong, normal maps are all messy, base tex goes black on black and ambient occlusion..well i wont go into that one...
i know a simple reinstall might fix it, but i just wanted to share the experiance with you..considering i actually only changed the language
i wanted to set it to german language (wich was a big mistake anyways because this is not german...its googiberrish...
Heeehe! You caught me: yes I used the always-awesome google translator
There is a file called ui\localization_german.xml with the strings that you can customize.
About the errors, in theory, the translations should only affect a few labels or, perhaps, not allow to start the program if some file is not well formated... but bugs can be amazingly disturbing sometimes ... I'll try to figure what could be happening, but the german version appears to run well my computer.
i feel a bit stupid right now, i am trying to install the photoshop plugins...
i copied em into my plugins folder of my cs4, and it wont show em in the plugins menu.
i feel a bit stupid right now, i am trying to install the photoshop plugins...
i copied em into my plugins folder of my cs4, and it wont show em in the plugins menu.
Why you don't simply re-install xNormal? Sure the PS plugins are checked when you install xNormal.
If you still want to copy them manually, copy the files from
[xNormal install folder]\x86\photoshop_plugins\*.8BF to
[PSCS4 folder]\Adobe Photoshop CS4\Plug-Ins\Filters
Notice if you have the x64 version installed you'll need to use the x64 ones:
[xNormal install folder]\x64\photoshop_plugins\*.8BF to
[PSCS4 folder x64]\Adobe Photoshop CS4\Plug-Ins\Filters
You'll need the .NET 2.0 and the VC++ 2005 SP1 runtimes too.
off topic here, but chai: you should make a modo script that sets all of your uv boarders to be hard edged, if you're doing all this smoothing group stuff there.
Yes my plugin is pretty much finished with hardedge support etc ... still wanna test it better with xNormal and maybe add a video/pdf explaining usage. (don't worry is much simpler than the prototype I sent ya long time ago)
I'll be sure to drop you a note when it's officially released, probably a week or two.
Oooopz! I'll fix it for the final 3.16.12 version.
As jeff said, neither 127 nor 128 is correct.
the correct is 127.5... but that's impossible for a RGB8 integer format...
I've seen usually a 127,127,255 value in other programs.
Do you know any other bug? I plan to release the final 3.16.12 the next week.
hmm, would 127.128.255 be closer then ?
these are the rgb vs hex vs decimal comparision of all three and seems 127.128.255 is in middle
these are the rgb vs hex vs decimal comparision of all three and seems 127.128.255 is in middle
127.127.255 = 7F7FFF = 8355839
127.128.255 = 7F80FF = 8356095
128.128.255 = 8080FF = 8421631
Probably you should consider each channel independently and not as a merged integer value.
The normal maps are not really a "color" map, so you neither can apply a eye-luminance sensibility weighting.
The human eye is more sensible to the green channel as you can see in this image:
If I remember well the 3dfx Voodoo used R5G6B5 16bits color format in the past... but a normal map it's not a color really
We just want to quantise each normal map's channel from the [-1.0,1.0] range to the the [0,255] one. The operation is called commoly "biasing" and it's performed optimally by the GPU making a *0.5+0.5 MAD(multiply-add) operation.
A completely flat Ts-normal is ( 0, 0, 1 ), which maps to
( 0, 0, 1 )*0.5 + 0.5 = ( 0.5, 0.5, 1 ) * 255 = ( 127.5, 127.5, 255 )
Like we use an unsigned integer RGB8 format we won't have decimal parts, so (127,127,255), ( 128,128,255 ),( 127,128,255) or ( 128,127,255 ) can be acceptable but they're all incorrect.
There are other problems, though:
1. The GPU MAD operation has reduced precision in order to gain speed. That means 127.5 will be probably 127.4999 or 127.51999...
This has the same problem of the 128 : the value can be a bit above or below the magic 127.5
2. Most of the GPUs use a lot of fixed point maths. Each time you perform an arithmetic operation or a type cast, you'll loose precision.
3. The trilinear-filtered mipmapping gonna destroy our cold-carefully-planned values. Ideally you should compute each normal map's mipmap individually, taking care of the background color... BUT, Forceware/Catalyst drivers usually have an option to control(ignore really) the mipmap quality. DX/OGL have also an option to auto-generate the mipmaps, so mipmaps gonna be evil !
4. We cannot use a 16bits integer texture format nor a floating point one because some cards don't support them !
I've just uploaded the 3.16.13 with the ZB3.5/PolyPaint OBJ problem fixed.
The examples are now dettached from the installer and are available as a separate download ( so the installer now occupies "just" 44Mb ).
Its funny i've always heard the "NEVER RESIZE, ALWAYS REBAKE YOUR MAPS!" argument, but i very often size down maps without any negative visual artifacts. Comparing rebaked maps at a lower resolution(say 256 baked, or 1024 resized to 256) to a resampled texture created in photoshop, the resampled result always seems better(because of better anti-aliasing, and it seems to retain details better as well) and i've never really had any problems where the normal map somehow gets "broken" from resizing, but yet every programmer i've ever talked to says that this is a really bad thing to do. Seems like one of these things that makes some sense in theory, but in practice isnt actually a problem.
And yeah, compressed textures are going to fuck it all up in the end no matter what =(
Its funny i've always heard the "NEVER RESIZE, ALWAYS REBAKE YOUR MAPS!" argument, but i very often size down maps without any negative visual artifacts. Comparing rebaked maps at a lower resolution(say 256 baked, or 1024 resized to 256) to a resampled texture created in photoshop, the resampled result always seems better(because of better anti-aliasing, and it seems to retain details better as well) and i've never really had any problems where the normal map somehow gets "broken" from resizing, but yet every programmer i've ever talked to says that this is a really bad thing to do. Seems like one of these things that makes some sense in theory, but in practice isnt actually a problem.
Resizing in photoshop has better antialiasing because the normal map isn't normalized.
So if you resize and then normalize, you would get 99% the same result of rebaking it.
If I recall correctly those are less effecient from gpu acceleration point of view. (even though they look better from artist point of view)
I always bake at one size larger and resize down - anti aliasing is better. Even if you do insane rays for AA - resizing will be better AA'd and usually faster since you can go bigger with less rays. Yeah, "technically" not correct, but this is art for fucks sake, not building a rocket ship. Just make sure to normalize afterwords, even though the differences will be very minor.
hey thr,
Having some troubles with xnormal and hoping you can help me out.
I am trying to bake a normal map but whenever I click the generate map button I now get an error that says
" Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
What exactly does that mean and how do I fix it?
I have looked over all my system hardware and everything seems to be working fine otherwise. I had successfully baked several maps earlier today but then Xnormal crashed and when I started it again and tried to bake again I get that error. I have tried restarting my system, to no effect.
In addition to that, I have one more problem. I can not seem to get the 3d viewer to work in any capacity. Since installing xnormal I have not once gotten the viewer to open. When I click the launch viewer button, the viewer opens its screen and then begins to load the viewer, but just before it is done it crashes and gies me the error; " Unexpected error showing the viewer 3D"
I was using an older version but updated to the newest version, hoping that would fix it, but still have the same problem.
hey thr,
Having some troubles with xnormal and hoping you can help me out.
I am trying to bake a normal map but whenever I click the generate map button I now get an error that says
" Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
What exactly does that mean and how do I fix it?
I have looked over all my system hardware and everything seems to be working fine otherwise. I had successfully baked several maps earlier today but then Xnormal crashed and when I started it again and tried to bake again I get that error. I have tried restarting my system, to no effect.
In addition to that, I have one more problem. I can not seem to get the 3d viewer to work in any capacity. Since installing xnormal I have not once gotten the viewer to open. When I click the launch viewer button, the viewer opens its screen and then begins to load the viewer, but just before it is done it crashes and gies me the error; " Unexpected error showing the viewer 3D"
I was using an older version but updated to the newest version, hoping that would fix it, but still have the same problem.
Any ideas or help would be appreciated. thx.
I would assume the 2nd issue is because you're using an old/unsupported video card?
EQ- well my video card is a 512mb Geforce 8600GT.
Don't know if that's to old, but I would hope not. And its a fairly common card, I would think, so I would hope it would be supported. But don't know for sure. Is there a list of what is supported somewhere?
After many tests I've finally found the issue of my problem.
EarthQuake you're going to like this, my issues were because the xNormal map wasn't normalized !
Also I've also noticed xNormal sets a flat normal to (127,127,255) instead of (128,128,255), might be worth mentioning.
OBlastradiusO : my .obj exporter for modo is due to release next week, and works fine with xnormal/marmoset.
After many tests I've finally found the issue of my problem.
EarthQuake you're going to like this, my issues were because the xNormal map wasn't normalized !
Also I've also noticed xNormal sets a flat normal to (127,127,255) instead of (128,128,255), might be worth mentioning.
OBlastradiusO : my .obj exporter for modo is due to release next week, and works fine with xnormal/marmoset.
EQ- well my video card is a 512mb Geforce 8600GT.
Don't know if that's to old, but I would hope not. And its a fairly common card, I would think, so I would hope it would be supported. But don't know for sure. Is there a list of what is supported somewhere?
I use a 8600GT too!
Any graphics card should be supported... because the 3D viewer supports PS1/2/3 in DX9, PS4 in DX10 and OpenGL 1.3+GLSL.
About the CPU, any processor with SSE(pentium3/athlon XP or above) should be fine.
Btw... do you have a laptop with an Intel GMA? What OS and CPU do you use? Did you overlock the GPU or the CPU? Can you play Crysis, WoW, Quake Wars and other games well? Can you run the xNormal examples without problem?
Any graphics card should be supported... because the 3D viewer supports PS1/2/3 in DX9, PS4 in DX10 and OpenGL 1.3+GLSL.
About the CPU, any processor with SSE(pentium3/athlon XP or above) should be fine.
Btw... do you have a laptop with an Intel GMA? What OS and CPU do you use? Did you overlock the GPU or the CPU? Can you play Crysis, WoW, Quake Wars and other games well? Can you run the xNormal examples without problem?
No laptop, I have a tower. I don't overclock anything. Current OS is windows xp and cpu is intel core2 quad 2.4 ghz. Yes I can run all those games fine and I can load any of the examples without a problem too.
edit: I did try other meshes as EQ suggested and I didnt get the error when rendering the maps. So has to be something with my mesh. Not sure how or what is wrong with it but going to try and figure it out.
well no matter what mesh I use I still cant get the viewer to work. It experiences and unexpected error every time.
As for the other issue, It is most certainly my mesh. I tried exporting it as different file formats, I tried resetting xforms again, I tried unifying the normals, I checked all my UVs and have no missing faces. Now instead of the error it either crashes xnormal or produces a solid blue square for the normal map.
Then I tried importing both the high rez and the low rez into zbrush. This showed me how screwed up the mesh is. When I import either mesh (separately) they have the same general shape as my model but they have a spiderweb of faces going and wrapping all over the model . Its a mess to say the least. I have no idea what is causing it. I even when back and exported older versions of the model which were saved under a different name and even those appear as a mess.
It was fine up till the other day and then suddenly it all went hay wire. Everything looks just fine in max but not any where else.
Think I might need to make a different forum post about it because it would be a shame to lose the mesh and I really don't want to start over.
@AnimeAngel, I found the problem with your OBJ. It's using negative face indices... which is ok according the OBJ format, but most of the importers/exporters around aren't prepared for that: they expect positive indices.
In theory xNormal was prepared for this.... but, unfortunately, I optimized the internal text parser some time ago and I forgot about that feature
So just re-export your OBJs with some kind of "Use relative numbers" option disabled. See what 3dsmax's help says about this:
Relative numbers Causes face vertex indices in exported files to be expressed as relative (i.e., negative) numbers. This can cause compatibility issues when importing with certain programs. If you're unable to import an OBJ file, make sure this option is off and export again.
Are you using an external cage? Try to clear the "external cage file" slot ( right click -> reset external cage file ).
Ya that's what I mean, it would work if I reset it - but I don't see why it should check it if I just tick it off (I always use the same lowpoly and cage files anyway) - so just wanted to share it
Thanks for creating this software but I'm having problems with getting it to work at all. I am on a quite low end pc (laptop with 1.5GB memory, 128mb ATI Rad X700) and kept getting the
Attempted to read or write protected memory. This is often an indication that other memory is corrupt
message while it generated. I imported into max and made sure relative numbers was turned off and re-exported but still the same. Here are the files if you want to see for yourself,
Ya that's what I mean, it would work if I reset it - but I don't see why it should check it if I just tick it off (I always use the same lowpoly and cage files anyway) - so just wanted to share it
If you add/insert any vertex or face in the external cage, it will show the mismatch message. The topology of the external cage must be exactly equal to the lowpoly mesh's one.
I should not load the external cage if you don't check in the "Use cage" option though... I'll fix it.
Thanks for creating this software but I'm having problems with getting it to work at all. I am on a quite low end pc (laptop with 1.5GB memory, 128mb ATI Rad X700) and kept getting the
Attempted to read or write protected memory. This is often an indication that other memory is corrupt
message while it generated. I imported into max and made sure relative numbers was turned off and re-exported but still the same. Here are the files if you want to see for yourself,
The 3.16.13 works for me. How much memory do you have free? Pls, do a CTRL+ALT+DEL and see the free memory available. If it's less than 256Mb it simply won't run.... and sure your graphics drivers are updated and you're running the final 3.16.13 and not a Release Candidate/Beta.
Btw, I write a txt log with the errors in My Documents\xNormal\xNormal_debugLog.txt if you want to take a look.
you are still rocking, nothing as good as xnormal out there
the only thing i don't like is how setting ao sample length works. The lenghts is used for general trace distance and ao sample length, which makes baking a long ao length without lot's of artefacts impossible.
If you add/insert any vertex or face in the external cage, it will show the mismatch message. The topology of the external cage must be exactly equal to the lowpoly mesh's one.
I should not load the external cage if you don't check in the "Use cage" option though... I'll fix it.
cheers jogshy !
I always use the same lowpoly & cage files between assets, and it's great to have the option to enable/disable cage in one click rather than resetting and than browsing for the cage again
Replies
Working directly form modo is limited, fortunately I will soon finish upgrading my .obj exporter from modo.
It will support apply morph, automatic cage, resize, smoothgroups and vertex normals ... all in commandline format so it can be farther automated
The default background color for normal maps in the latest release is 126, 126, 255.
It should be 128, 128, 255
I gotta say, I like the ability to have different background colors for each map type with the bake, it's saving me a step. =]
Just to clarify, because the range is 0-255, 127 is the exact middle, not 128(if the range was 1-256)
or is it 127.5? Fuck, Santi, we need more range in our pixels here buddy.
off topic here, but chai: you should make a modo script that sets all of your uv boarders to be hard edged, if you're doing all this smoothing group stuff there.
I always end up with visible seams when I use 127 as the mid value and overlaying multiple normal maps onto each other, which is not so when I use 128, whether it's correct or not.
jeffrussell: so the math to expand is this:
jeffrussell: 2*(tex/255) - 1
jeffrussell: so there's no integer in there that gives you exactly 0
jeffrussell: you can try both 127 and 128
jeffrussell: 127 slightly under 0, 128 slightly over
Its interesting that you get errors with 127, maybe you're doing something incorrectly when overlaying them(like not clamping the levels to 127 in blue)? Both 127 and 128 should be *equally* wrong, from what its been explained to me. Also when i render a flat plane onto itself i get a 127,127,255 map, atleast from xn. I wonder if this is an engine/shade specific thing.
It's been a while since I've tried using the 127, chances are I just wasn't good at editing normal maps back then.
Just out of curiosity, what software do you view your models in?
I'm using Maya, which the 128 problem may have something to do with how it reads the data.
As jeff said, neither 127 nor 128 is correct.
the correct is 127.5... but that's impossible for a RGB8 integer format...
I've seen usually a 127,127,255 value in other programs.
Do you know any other bug? I plan to release the final 3.16.12 the next week.
i wanted to set it to german language (wich was a big mistake anyways because this is not german...its googiberrish... well and now everything is set up just wrong, normal maps are all messy, base tex goes black on black and ambient occlusion..well i wont go into that one...
i know a simple reinstall might fix it, but i just wanted to share the experiance with you..considering i actually only changed the language
Heeehe! You caught me: yes I used the always-awesome google translator
There is a file called ui\localization_german.xml with the strings that you can customize.
About the errors, in theory, the translations should only affect a few labels or, perhaps, not allow to start the program if some file is not well formated... but bugs can be amazingly disturbing sometimes ... I'll try to figure what could be happening, but the german version appears to run well my computer.
i feel a bit stupid right now, i am trying to install the photoshop plugins...
i copied em into my plugins folder of my cs4, and it wont show em in the plugins menu.
If you still want to copy them manually, copy the files from
[xNormal install folder]\x86\photoshop_plugins\*.8BF to
[PSCS4 folder]\Adobe Photoshop CS4\Plug-Ins\Filters
Notice if you have the x64 version installed you'll need to use the x64 ones:
[xNormal install folder]\x64\photoshop_plugins\*.8BF to
[PSCS4 folder x64]\Adobe Photoshop CS4\Plug-Ins\Filters
You'll need the .NET 2.0 and the VC++ 2005 SP1 runtimes too.
Yes my plugin is pretty much finished with hardedge support etc ... still wanna test it better with xNormal and maybe add a video/pdf explaining usage. (don't worry is much simpler than the prototype I sent ya long time ago)
I'll be sure to drop you a note when it's officially released, probably a week or two.
hmm, would 127.128.255 be closer then ?
these are the rgb vs hex vs decimal comparision of all three and seems 127.128.255 is in middle
127.127.255 = 7F7FFF = 8355839
127.128.255 = 7F80FF = 8356095
128.128.255 = 8080FF = 8421631
The normal maps are not really a "color" map, so you neither can apply a eye-luminance sensibility weighting.
The human eye is more sensible to the green channel as you can see in this image:
If I remember well the 3dfx Voodoo used R5G6B5 16bits color format in the past... but a normal map it's not a color really
We just want to quantise each normal map's channel from the [-1.0,1.0] range to the the [0,255] one. The operation is called commoly "biasing" and it's performed optimally by the GPU making a *0.5+0.5 MAD(multiply-add) operation.
-1 ... 1 * 0.5 = -0.5 .... 0.5
-0.5 ... 0.5 + 0.5 = 0 .... 1
0 ... 1 * 255 = 0 .... 255
A completely flat Ts-normal is ( 0, 0, 1 ), which maps to
( 0, 0, 1 )*0.5 + 0.5 = ( 0.5, 0.5, 1 ) * 255 = ( 127.5, 127.5, 255 )
Like we use an unsigned integer RGB8 format we won't have decimal parts, so (127,127,255), ( 128,128,255 ),( 127,128,255) or ( 128,127,255 ) can be acceptable but they're all incorrect.
There are other problems, though:
1. The GPU MAD operation has reduced precision in order to gain speed. That means 127.5 will be probably 127.4999 or 127.51999...
This has the same problem of the 128 : the value can be a bit above or below the magic 127.5
2. Most of the GPUs use a lot of fixed point maths. Each time you perform an arithmetic operation or a type cast, you'll loose precision.
3. The trilinear-filtered mipmapping gonna destroy our cold-carefully-planned values. Ideally you should compute each normal map's mipmap individually, taking care of the background color... BUT, Forceware/Catalyst drivers usually have an option to control(ignore really) the mipmap quality. DX/OGL have also an option to auto-generate the mipmaps, so mipmaps gonna be evil !
4. We cannot use a 16bits integer texture format nor a floating point one because some cards don't support them !
5. Texture compression gonna anihilate our precise maths !
Soooooo... just don't care about 127 or 128
The examples are now dettached from the installer and are available as a separate download ( so the installer now occupies "just" 44Mb ).
And yeah, compressed textures are going to fuck it all up in the end no matter what =(
Resizing in photoshop has better antialiasing because the normal map isn't normalized.
So if you resize and then normalize, you would get 99% the same result of rebaking it.
If I recall correctly those are less effecient from gpu acceleration point of view. (even though they look better from artist point of view)
Having some troubles with xnormal and hoping you can help me out.
I am trying to bake a normal map but whenever I click the generate map button I now get an error that says
" Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
What exactly does that mean and how do I fix it?
I have looked over all my system hardware and everything seems to be working fine otherwise. I had successfully baked several maps earlier today but then Xnormal crashed and when I started it again and tried to bake again I get that error. I have tried restarting my system, to no effect.
In addition to that, I have one more problem. I can not seem to get the 3d viewer to work in any capacity. Since installing xnormal I have not once gotten the viewer to open. When I click the launch viewer button, the viewer opens its screen and then begins to load the viewer, but just before it is done it crashes and gies me the error; " Unexpected error showing the viewer 3D"
I was using an older version but updated to the newest version, hoping that would fix it, but still have the same problem.
Any ideas or help would be appreciated. thx.
I never had this problem with other bake programs, below is a comparison with a 3dsmax bake.
(viewed in realtime 3dsmax viewport)
I would really appreciate any feedback here !
I would assume the 2nd issue is because you're using an old/unsupported video card?
Don't know if that's to old, but I would hope not. And its a fairly common card, I would think, so I would hope it would be supported. But don't know for sure. Is there a list of what is supported somewhere?
i've seen that error before i think, it may be somehow corrupted uvs/normals?
like maybe you have only partial uvs, some faces dont exsist in the uv channel, that would cause problems, think about things like that
EarthQuake you're going to like this, my issues were because the xNormal map wasn't normalized !
Also I've also noticed xNormal sets a flat normal to (127,127,255) instead of (128,128,255), might be worth mentioning.
OBlastradiusO : my .obj exporter for modo is due to release next week, and works fine with xnormal/marmoset.
Cool. Thank you.
I use a 8600GT too!
Any graphics card should be supported... because the 3D viewer supports PS1/2/3 in DX9, PS4 in DX10 and OpenGL 1.3+GLSL.
About the CPU, any processor with SSE(pentium3/athlon XP or above) should be fine.
Btw... do you have a laptop with an Intel GMA? What OS and CPU do you use? Did you overlock the GPU or the CPU? Can you play Crysis, WoW, Quake Wars and other games well? Can you run the xNormal examples without problem?
No laptop, I have a tower. I don't overclock anything. Current OS is windows xp and cpu is intel core2 quad 2.4 ghz. Yes I can run all those games fine and I can load any of the examples without a problem too.
edit: I did try other meshes as EQ suggested and I didnt get the error when rendering the maps. So has to be something with my mesh. Not sure how or what is wrong with it but going to try and figure it out.
As for the other issue, It is most certainly my mesh. I tried exporting it as different file formats, I tried resetting xforms again, I tried unifying the normals, I checked all my UVs and have no missing faces. Now instead of the error it either crashes xnormal or produces a solid blue square for the normal map.
Then I tried importing both the high rez and the low rez into zbrush. This showed me how screwed up the mesh is. When I import either mesh (separately) they have the same general shape as my model but they have a spiderweb of faces going and wrapping all over the model . Its a mess to say the least. I have no idea what is causing it. I even when back and exported older versions of the model which were saved under a different name and even those appear as a mess.
It was fine up till the other day and then suddenly it all went hay wire. Everything looks just fine in max but not any where else.
Think I might need to make a different forum post about it because it would be a shame to lose the mesh and I really don't want to start over.
Send me that conflictive OBJ if you want! I'll debug it!
Hmmmm, interesting. I'll take a look.
I've released my plugin, which was specially revamped for xNormal.
http://forums.luxology.com/discussion/topic.aspx?id=41509
In theory xNormal was prepared for this.... but, unfortunately, I optimized the internal text parser some time ago and I forgot about that feature
So just re-export your OBJs with some kind of "Use relative numbers" option disabled. See what 3dsmax's help says about this:
Relative numbers Causes face vertex indices in exported files to be expressed as relative (i.e., negative) numbers. This can cause compatibility issues when importing with certain programs. If you're unable to import an OBJ file, make sure this option is off and export again.
I'll fix it for the next xn release.
The link points to http://pipelineio_v0.8.rar/ hehe
Excellent thanks! You're a timesaver!
no worries OBlastradiusO !
feel free to post feedback/questions in that thread, as I'm always looking to improve and streamline the plugin/docs
Question for you at the lux forum
Looks fine now thanks!
Ya that's what I mean, it would work if I reset it - but I don't see why it should check it if I just tick it off (I always use the same lowpoly and cage files anyway) - so just wanted to share it
Thanks for creating this software but I'm having problems with getting it to work at all. I am on a quite low end pc (laptop with 1.5GB memory, 128mb ATI Rad X700) and kept getting the
Attempted to read or write protected memory. This is often an indication that other memory is corrupt
message while it generated. I imported into max and made sure relative numbers was turned off and re-exported but still the same. Here are the files if you want to see for yourself,
http://www.caponeart.com/delxnormal.rar
I should not load the external cage if you don't check in the "Use cage" option though... I'll fix it.
The 3.16.13 works for me. How much memory do you have free? Pls, do a CTRL+ALT+DEL and see the free memory available. If it's less than 256Mb it simply won't run.... and sure your graphics drivers are updated and you're running the final 3.16.13 and not a Release Candidate/Beta.
Btw, I write a txt log with the errors in My Documents\xNormal\xNormal_debugLog.txt if you want to take a look.
the only thing i don't like is how setting ao sample length works. The lenghts is used for general trace distance and ao sample length, which makes baking a long ao length without lot's of artefacts impossible.
cheers jogshy !
I always use the same lowpoly & cage files between assets, and it's great to have the option to enable/disable cage in one click rather than resetting and than browsing for the cage again