GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion

[Entropy Soldier]

Despite splitting the test map up into extremely small rooms, i still encounter that texture compression error. I have checked to be certain, and zeroing out all the room coords does result in all the rooms moving to the same spot (and yet only two of the rooms experience texture errors, and yet they are smaller that some non-afflicted rooms.)


I use blender 2.4, as the currently available version messes up the map verticies when i export it.


Do any of you have the slightest idea of what could be the issue?

It would be greatly appreciated, because i cannot proceed with this map without first resolving the issue at hand.

[bmw]

Entropy Soldier wrote:

I remember reading somewhere that the rooms distance from the center would cause these, though i assumed that convert to GE level centered the room, and would eliminate the problem if the room was small enough.

That problem was specific to using Crafty to convert the room from a .bsp file to a .obj file. If I recall, this was a problem specific to Crafty that for some reason, if a room was a certain distance from center, the .obj file it would export would have messed up textures.

Are you using Crafty to create your .obj files or something else?

[Entropy Soldier]

I use the method shown in TimEh's video tutorials, and his island map is free of errors. He may have used a diffrent method for that map, however.

anyway...The entire import process is something like:

hammer > crafty > XSI > Blender > GE

or

RMF > BSP > Crafty OBJ > XSI scene > XSI OBJ > BLENDER OBJ > GE format


So i suppose it does go through crafty at one point, although i would assume that going through XSI and blender would fix the issues that it would cause. I'll do some more testing.

[bmw]

Its most likely happening with crafty. In my testing, the .bsp file going into crafty was fine, but the .obj file coming out of crafty was corrupt.

As far as compiling a room centered on the axis - this referred to hammer - any rooms you're having trouble with, move them in hammer to the center and then compile them to a .bsp, then to crafty and see if that fixes your problems.

[Entropy Soldier]

hmmm...well, the obj i'm exporting from crafty isn't corrupt in any way, its only upon importation to the setup editor that the errors occur.

Unless, of course, you mean that you tested it by importing it into GE using different programs and crafty was the only corrupt one, in which case, is there a better BSP to OBJ conversion program, or is it a necessity to center the rooms in hammer?

[Entropy Soldier]

Hmmmm...

Well, i did my tests, and found that regardless of how it is imported after getting converted to an obj by crafty, it still has the exact same texture errors. I even tried modifying the obj file and mtl file in notepad, but to no avail. Unfourtunatley, i cannot seem to find a way to convert a bsp to an obj without it, since the only other program i find, bsp2obj, says the bsp is not in the right format, so i can't even be sure crafty is the issue.

The only map i know of free of these errors (for the most part) is timeh's island (i'm wondering if this is due to the fact that he uses the "normal" compile tools and not zoners, too bad i don't have the configuration for them anymore...i'll look for it later). Unfortunately, he doesn't come by too often, and i don't want to optimize this further (since it will take a lot of work, considering the size[14k polys] and how much hammer destroyed it) unless I'm certain i can import this with no texture errors (since they really ruin the feel of the map).

I have other GE related projects i can also do, but I'd really like to get this done soon. <_>

[Camaro]

there was a program called bsp2obj but i haven't found a working version of it. You could maybe try texturing with XSI? I believe that is how TimEh textured his map because that is how he does it in the tutorials.
_________________
304 HP

[Wreck]

Here is what TimEh said about the texture error issue in his Island map...

TimEh wrote:

Many textures have incorrect U/V's. After painstakingly fixing over 50 of the more important U/v's by hex editor, I figured I'd just stretch the rest out.

I performed the same task with a test room I designed in Hammer, which suffered from poorly drawn textures. I was using more guess-work than anything, so maybe he has more technical knowledge of this procedure.
_________________

YOUTUBE | TWITTER/X | FACEBOOK | VAULT | MOD DB | RHDN

[radorn]

This brings up a question:
What are the limits for UV coordinates in the GE BG fileformat?
I believe UV's go like this.
One of the corners of the texture (upper left?) is coordinate 0.0 and the horizontally or vertically opposite corner of the texture would be 0.9999999999.
1.0 would mean the first pixel (or fraction of a pixel) after the first loop.
So, what are the max values for UV coords? SubDrag? I would like to know so I can know how many texture loops can be crammed in before problems arise.

[TimEh]

ok so i just explained it to Entropy Soldier with PM but i guess i should explain here. The problem the textures are doing this is because the U/V's only support 16-bit floats.

Quote:

So, what are the max values for UV coords? SubDrag? I would like to know so I can know how many texture loops can be crammed in before problems arise.

well its not really the exact limit thats the problem. as these small floats are impersice and the problem could arise before that limit. Dont think of it like a normal int that wraps around once it hits its limit and thats whats causing the prob. looking at the 16-bit IEEE 754 float we see that 1-bit is for sign, 5-bit for the exponent and the rest for the mantissa. As you can see thats not much room for anything and is not really ment for large numbers with decimals as alot of info will be stripped durring the conversion. bla bla bla

Problem, U/V coords stray to far away from the center. The farther away, the greater chance of crazy stuff happening

the fix, just bring things closer to the middle. I know in my tutorials for texturin i just selected all the polys and selected best fit with the unfolded cube thing. But since that lays every peice out flat, when scaleing the U/V's larger, the outer polygons will be far away from the origin. So just import into the game, make a note of what polygons are trippin out, go back to the editor and manualy arange those polygons closer to the center of the U/V map.

Now if its just one polyon. But you want the texture to be very small and repeatible. Just split the poly in half and center them apon thee U/V map

hope this info helps

oh, and u/v coords work like this

Code:

(0,0)        (1,0) ______________ |             | |             | |             | |    texture  | |             | |_____________| (0,1)         (1,1)

[TimEh]

and the reason i didnt fix it in Island was because when i found out the large float numbers were the problem, i already had the lighting done and didnt want to make changes in XSI, then redo all the hand made lighting stuff again.

[radorn]

I guess another good guideline to avoid problems would be not to make too large meshes of triangles sharing vertices, and divide them in smaller "blocks" instead.

[Entropy Soldier]

Well, thanks to TimEh's help, i can finally proceed with the importing of this map.

For reference, to center the U/V's in XSI, you need to highlight the polys you want to fix, open the textures tab, go to projection, and find the translate tool.
Then move the textures around until the U/V is as close to 0 as possible, while still maintaining the alignment with textures near it.
You can use the pan/zoom tool in the projection editor to zoom in and effectively cause the texture movement to be slower/more precise.

If anyone still has problems with texture errors, feel free to PM me or find me in the chat. (E-S)

[Wreck]

Sounds great!
Maybe we can finally rid ourselves of the nasty texture errors that have plagued almost every custom map built thus far. We all know how unflattering it is to have stretched out or overly repeated textures on walls and floors, so anyway we can iron out those flaws is definitely welcome.
_________________

YOUTUBE | TWITTER/X | FACEBOOK | VAULT | MOD DB | RHDN

[Entropy Soldier]

Well, I'm nearly done with optimizing this map in XSI.

went from 12706 tri's to around 9000.


Or at least that's what XSI thinks. The stairs create a -ton- of splits on the walls where there could easily be only one or two tri's. I tried deleting the edges, but the tri count doesn't go down. Is it doing so in reality, but just not in XSI's calculations?

Also, i seem to get a bunch of flat ploys when i optimize heavily split areas. Is there any way to dispose of these, or should i just be careful not so include any when splitting up into rooms?


Anyway, assuming i don't run into any more issues, i should have an alpha of the map geometry imported into the game soon for anyone who wants to check it out.

Also, considering the number of tri's (which i think is much less, but i have no idea). Do you think extra steps need to be taken to get this to run well with four players? (tinted glass, lots of rooms, etc)

Anyway, all i have left to do is the excutive office area, upper cubicle area, and the center room.




Well, i figure the number of tri's in this room can easily be cut into a third of what it is now.

I'll also be adding railings to the catwalk, if your wondering why the supports do not reach it.