Plan for Joe Sulewski

Submit your own resources!

wingman   (Jun 14, 2004 at 19:23 GMT)

Im about to post a .plan on a ms2map exporter me and Rick Kelley (Rat) are working on. We have run into the same problem as you with texture offsets. Ill post a tad more info in my plan.

Joe Sulewski   (Jun 14, 2004 at 19:36 GMT)

What a relief, at least I know I'm not alone and somebody understands my writing style. Let's collaborate and perhaps we can both finish our respective plans. By the way, what is ms2map. I get the 2map part but what about the ms?

Joe

wingman   (Jun 14, 2004 at 19:55 GMT)

milkshape
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=5852
Edited on Jun 14, 2004 19:56 GMT

Josh Williams   (Jun 15, 2004 at 16:02 GMT)

Hey, these look really interesting guys! Coolness.

Joe Sulewski   (Jun 15, 2004 at 16:11 GMT)

Thanks Josh. You know of anybody who understands the interior code enough to possibly throw some hints my way? These offset issues are really holding me back. If I can get those taken care of I can move forward at a faster pace.

Shadowdragon   (Jun 19, 2004 at 01:31 GMT)

Hey I hope you get everything working properly. Since a blender2map exporter is what the project I'm modeling for, is in dire need of.

Rick Kelley   (Jun 21, 2004 at 04:37 GMT)

Hi, Joe, I am the one working on the Milkshape torque map exporter plugin. I would like to know if you have had any success in finding out on how to arrive at the texture axis computations? I would like to discuss with you what little bits of infomation I have found around the web on it.

Joe Sulewski   (Jun 21, 2004 at 12:49 GMT)

I think I have Rick. E-Mail me and we'll exchange information this way this discussion doesn't get cluttered with non sequiturs.

Joe Sulewski   (Jun 21, 2004 at 12:58 GMT)

Shadow dragon,

If your willing to help me test I will make sure to send you updates as soon as I think it's testable.

EddieRay   (Jun 25, 2004 at 20:03 GMT)   Resource Rating: 4

Hey,

Deep in the Interiors code, you can see where the MAP-style texture coordinates are converted back to UVs at render time. The equations it uses to compute the UVs are essentially:

U = Sx * x + Sy * y + Sz * z + Sw
V = Tx * x + Ty * y + Tz * z + Tw

where S and T are the MAP-style texture vectors (with x,y,z,w components), and x,y,z are the coordinates of each vertex in the triangle.

If you dig through the MAX2MAP code, there is a section that is devoted to solving the reverse problem - if I have UVs, what are the corresponding S-T vectors? Take a look at it. It essentially boils down to solving the above equations for S and T, and creating a system of equations that uses the 3 points of the triangle, the known UV values for each point, and a fourth equation that describes how the S and T vectors lie in the plane of the triangle (IIRC).

I've played with the code, and gotten pretty close to getting it to work, but it's not exactly correct. One problem is that it appears you must normalize the S and T vectors after performing the calculations. Even then, I still don't get the correct mappings, so I'm still missing something.

Another idea I've been thinking about is to make it possible in the Interior rendering code to use straight UV coords that are stored in the normal S and T vectors, but using some "hack" to let the Interior rendering code know whether we're actually specifiying UVs or just the normal S-T vectors (possibly, we could set Sw or Tw to something other than 0 - IIRC Sw and Tw are always 0). Of course, I'd only want to do it if it could be down without modifying the data structures. Also, it would be necessary to make sure MAP2DIF will work with UVs (i.e. pass them through unscathed).

One problem with using UVs instead of S-T vectors is that we'd need to specify all 3 UVs for each triangle - by cramming them into a single S-T pair, since there is only one S-T pair for each triangle, but there just happens to be 8 floats available, and we only need 6. ;-)

Anyway, you probably know some/all of this, but I hope this helps...

Ed
Edited on Nov 30, 2004 17:36 GMT

Rick Kelley   (Jul 04, 2004 at 03:11 GMT)

Ok I did a search on this MAP2MAX code, and it yields nothing. In fact the threads that are pointed to by google to the garage game forums are broken or dead links. Where did you get this code? I would love to see it if possiable. I keep coming up with dead ends, and anyone in the know of the enhanced texture tuplet code portion seems to be not interested in sharing knowledge. I am almost ready to just try and rewrite the compiler to accept the old quake format which is how I can get my present plugin to spit out a MAP that quark will accept and fix with the Torque->Export220Map/Build High Detail DIF... command menu item.

EddieRay   (Jul 06, 2004 at 15:06 GMT)   Resource Rating: 4

Sorry for the confusion... it's called "MAX2MAP" (not "MAP2MAX") and it's part of the TGE source under tools/max2mapExporter.

If you look in main.cc at line 437, you'll find the beginning of a "for" loop that goes through every triangle of a mesh and does the calculations I describe above to create a "surface" for an Interior, and as part of that process, computes the S and T vectors (which are referred to as "gens") for each triangle. At line 494, there are some initializations, and then the meat of the calculations are performed for a single triangle, down to line 533 where the new MAP-style surface is added to the "mix".

By the way, I'm referring to the 1.2.2 TGE source.

Hope this helps...
Edited on Jul 06, 2004 15:09 GMT

Joe Sulewski   (Jul 06, 2004 at 15:09 GMT)

Ed,

Thanks a lot for the tip, perhaps it will help me figure how to deal with the offsets.

Joe

EddieRay   (Jul 06, 2004 at 15:17 GMT)   Resource Rating: 4

No problem. It's not really "offsets", as you show in your analysis above. What you're seeing is the result of mapping from UV-space to ST-space and then back again. The main problem is that UV-space for an Interior a function of world coordinates of the vertices, unlike the normal use of UV-coords. This is generally considered to be a "feature" for level design - since when you work in ST-space, you don't have to do any extra "work" to make textures seemless across adjacent objects. Unfortunately, in contrast, it makes simple UV-style "fit-to-face" and those kinds of mappings more difficult (if not impossible for some mappings).

It really would be nice to have a way to store UV coords in the S-T vectors and have the Interiors renderer convert from S-T or just reassemble the UVs automatically on the fly... ;-)

Joe Sulewski   (Jul 06, 2004 at 23:43 GMT)

Ed,

Thanks for the reply and you confirmed my belief that I had to convert the coordinates from UV space to ST space. But I thought the conversion was a simple matter of finding the correct vertex for the face. As an example, if the user didn't want to shift the texture (0,0 for UV coordinates) then the ST coordinate is a simple matter of using the lower left vertex of the face. But obviously I think I'm wrong since it doesn't work. :) Can you shed any light on this?

Thanks again,
Joe

Rick Kelley   (Jul 07, 2004 at 01:39 GMT)

I am not sure if this is right or not, but this is how I understand how triangle polygon soup works for Milkshape: The triangle is created from the first vertex, in a counter clockwise fashion. This information is stored in an array for the entire mesh. Now here is the kicker: This triangle can have absolutly nothing in common with another one that is even on the same plane as another, or perhaps a quad or more plane shape. i.e. in the case of a quad shape requiring two triangles, you could create the first one with the first vertex at the south west position. Then you create the next two in a CCW pattern, (south east, then north east). Next you create another triangle, (face), that starts its life with a vertex at the north east of where the other triangle was started, and then connect an edge to the first vertex of the first triangle, (south west), then complete it with an edge that connects to the 3rd vertex in the first triangle (north east). These two triangles would have different texture axis information in the modeler that needs to be transelated correctly for MAP space. This seems to be a big problem that I am having to deal with.
Edited on Jul 07, 2004 01:41 GMT

Joe Sulewski   (Jul 07, 2004 at 02:50 GMT)

Rick,

Does that mean that in Milkshape you can't have faces that are quads? All faces must have three points? In Blender I have quads or triangles so this makes life easy.

Back to your issue, if the two triangles create one face that exists on the same plane then the UV coordinates should be the same. Can you get the points of your mesh with no rotation, translation or scaling applied to the points? If so, then calculate your UV coordinates from that data. Then any faces that exist on the same plane as others will have the same UV coordinates. Once we figure out offsets (uv to st conversion) the textures should line up. Unless of course the two triangles that are used to create a face both have uv coordinates of 0,0. But they shouldn't they should have different UV coordinates. Applying the offset to the UV -> ST conversion should make everything match.

Of course I could be insane.

Joe

EddieRay   (Jul 07, 2004 at 03:10 GMT)   Resource Rating: 4

As I understand it, the S and T vectors are constants for an entire "surface" (or triangle in reality since all surfaces are made up of 3 points). And, the UV coords for a surface get calculated using the above equations in the Interiors renderer. So, conceptually, the UV coords are actually a function of the x,y,z coordinates of the vertices that make up the face.

In your example, to get a solution which yields values of U=0 and V=0 at one of the vertices, there are an infinite number of choices for the S and T vector components that will satisy the equations. However, when you take into account all 3 sets of UV values (one for each vertex), you start to narrow down the number of possible solutions, but it's still infinite. The basic assuptions are that the UVs are distinct (no duplicate UVs) and the vertices don't overlap (no triangles that are really a line or a point). So one way to narrow it down to a single solution for the S and T components is to pick values for Sw and Tw - I think the MAX2MAP code chooses 0 for both. Then you have 3 equations and 3 unknowns - and it's a matter of some straightforward (but a bit complex) math to solve the 3 equations (the gaussjInverse function is used to solve this problem in the MAX2MAP code - there are probably better ways but it's been a long time since I did this kind of linear algebra "simultaneous equations" stuff... ;-)

The trivial solution of setting S to [0,0,0,U] and T to [0,0,0,V] to yield the U=V=0 case doesn't work in general because it yields the same UV coords for each vertex regardless of x,y,z. So, the rest of the components really to need to be worked out too to provide a solution for all the S and T vectors that work for all 3 vertices.

Let's say we have a triangle with vertices:

P0 = [0,0,0]
U0 = 0, V0 = 0

P1 = [1,0,0]
U1 = 1, V1 = 0

P2 = [1,1,0]
U2 = 1, V2 = 1

By inspection, we can choose S = [1,0,0,0] and T = [0,1,0,0] to satisfy the equations. Now, it's easy to look at those S and T vectors and think, well S is really just "the U direction vector" and T is really just "the V direction vector". For simple mappings, like a cubic projection type of mapping, that might work. When there is translation involved, we could just use the "w" component of S and T to set the offset we need in each direction. But, when there is rotation involved, it gets a bit trickier. Also, you might notice that I picked simple x,y,z values that work very simply in the equations, but normally the x,y,z values for the verticies will be widely varied, and will not necessarily form a "right triangle" (which happens to have sides that line up nicely with coordinate axes), so you end up having to compute S and T components that take the size of the texture, the number of repeats and the world x,y,z distance between vertices into account.

Without rotation, you might be able to use equations like:

Sx = (Umax - Umin) / (Xmax - Xmin)
Sy = 0
Sz = 0
Sw = -Xmin * (Umax - Umin) / (Xmax - Xmin)

Tx = 0
Ty = (Vmax - Vmin) / (Ymax - Ymin)
Tz = 0
Tw = -Ymin * (Vmax - Vmin) / (Ymax - Ymin)

... or similar (my brain might be on the fritz). But, these equations assume that the face is oriented in a general direction, i.e., in this case, the face's normal is in the z direction. I've seen sections of code in various programs where they try to figure out which direction the face is generally pointing (up, down, left, right, front, back) and then choose an appropriate set of equations similar to the ones above to compute S and T components. However, in general, these equations don't produce any arbitrary mapping... only a "cubic projection" type of mapping, kinda like 6 projectors from up/down/left/right/top/bottom all aiming towards the origin (but not exactly like that).

Well, I'm starting to get bleary-eyed and I'm probably confusing the issue more than helping, but I hope you can gather some kind of insight from this... ;-)

Ed
Edited on Jul 07, 2004 04:22 GMT

EddieRay   (Jul 07, 2004 at 03:15 GMT)   Resource Rating: 4

By the way, don't worry about the "polygon soup" aspect too much. As long as the polygons (triangles) form convex solids, I think the TGE code will work out the BSP nature of it all. At least that's how I understand it... and that's the way MAX2MAP appears to be written - just hand all the triangles to the geometry "engine" and it'll figure out which polygons form solids, etc.

The part to worry about is making sure you feed it a set of polys that *do* actually describe a set of convex solids... i.e., use convex solids in the modeller before trying to convert the geometry for .MAP format.
Edited on Jul 07, 2004 04:25 GMT

Rick Kelley   (Jul 07, 2004 at 15:29 GMT)

Thanks for the walkthrough on the code. Btw Milkshape has a UV editor so the points about each and every vertex has its own set of UV coordinates is true. Thats what makes it difficult to transelate the information to something usuable for a MAP.

As for not worry about the polygon soup aspect, I would like to forget about it, but as in the past, your going to have users of the product doing unusal things with the modeler, so I am attempting to put some kind of sense to account for the odd cases. I have thought of just using the Valve brute force method that I have shared with Joe, where they have a look up table to referenced from the normals and crossproducts to set the plane worked upon to 1 of six choices of tuplets, then take this and use some math on these standards to figure in the scale and perhaps added rotational values.

Joe: as for how milkshape works, it works at the triangle level. Its one of the reasons its great for low polygon modeling, as there is no suprises with polygon levels being high like that of MAX and other high end modelers. Beside all of this, most game engines expect to have the player types of models in a tris manner or triangular data.
If you havent figured this out already, I am very unfamilar with texture coordinate space math, and I am a modeler and an artist first :D But I am a determined cuss, and I take an old motto by an old teacher of the russian language I had: "If I find I dont like a language, or understand how it works that will give me all the more reason to learn it!" I like to apply this to things like math and coding :D

Thanks once again.
Edited on Jul 07, 2004 17:01 GMT

Rick Kelley   (Jul 07, 2004 at 22:58 GMT)

I got some email from another person that wrote a map viewer utility, (views maps written out by the Worldcraft editor):

Well here are the forwards formulas:

W = 1 / TextureWidth
H = 1 / TextureHeight

U = (Dot(Vertex, UAxis) * W * (1 / UScale)) + (UShift * W))
V = (Dot(Vertex, VAxis) * H * (1 / VScale)) + (VShift * H))

I honestly have no idea how you can reverse them and I'm not sure that you
even can. You'd have to fill in what you know then solve for the unknowns
for each vertex of each face and hope all the solutions from each vertex
match. If they don't, I doubt there is a solution for that face. (And to
be honest, knowing how MilkShape creates its UV coordinates, I'd be
surprised if there is a face solution most of the time. Averaging the
vertex solutions might make for a somewhat accurate face solution.)

I believe that they always used the same style of UV generation; they just
didn't use the U and V axis values (they were hard coded). The original
Quake MAP format was just offset, scale and rotation and Valve made the U
and V axis dynamic (due to orientation problems).

You might find this interesting:

typedef struct tagBSPTEXTUREINFO
{
FLOAT U[3];
FLOAT UOffset;
FLOAT V[3];
FLOAT VOffset;
INT MipTextureIndex;
INT Flags;
} BSPTEXTUREINFO, *LPBSPTEXTUREINFO;

That is a structure form the HL BSP format. Each face does not store its
texture coordinates, just the axes and offsets (the scale and rotation are
calculated into each axis). HL uses that information to calculate BSP UV
coordinates.

Ryan Gregg
Edited on Jul 07, 2004 22:59 GMT

Joe Sulewski   (Jul 08, 2004 at 02:22 GMT)

Ed,

I looked at that code in max2map finally. It's been over 10 years since I've done anything resembling the gaussian inverse. I remember talking about it in class and wondering if I'd ever use it. :) But I can follow the code so perhaps I will try to port it python and see how that goes. I can't find a good reference on the algorithm of converting UV to ST on the net. I thought it would be easy to find. Your example above is great but I need to consider rotation, scaling and translation.

Thanks again, that pointer should help a lot. Now I'm onto trying to understand how to solve the three simultaneous equations. I did keep my books from college. Once I figure that out, applying what you described should help me a lot.

Thanks again,
Joe

ps I just looked at my linear algebra book and it's coming back. I think I understand the steps in the max2map code. I don't understand why were performing the steps (that would require understanding the UV -> ST transformation), but I think I'm starting to have the haze lift.
Edited on Jul 08, 2004 02:44 GMT

Joe Sulewski   (Jul 08, 2004 at 02:47 GMT)

Before I go on this venture, does anyone know if max2map works?
Edited on Jul 08, 2004 02:47 GMT

Rick Kelley   (Jul 08, 2004 at 20:58 GMT)

I tried it in max 4.2 and it bails with errors about undefined variables.

Heath Rezabek   (Nov 30, 2004 at 03:20 GMT)

Joe, i'm an artist and not a coder, so bear with me for chipping in; but i am also looking greatly forward to your resource, as i too am an OS X Torque developer and need to be able to get Blender objects into Torque as .maps .. what i suggest here is a kludge..;

if the offset error is consistent, one thing to try might be to deliberately plan for the offset error in the conversion. in other words, if a texture scaled to 1 shows up in Torque with 10% of its surface clipped, then why not scale the textures in Blender to .9? in theory, when the conversion takes place, they will scale up to the proper size, even though that size is technically in error. does this make sense? i ask about this [i'm sure you've tried or considered it already] because it is used a bit where i'm from converting color maps from Myth II to Myth III, which uses a different scale. so long as one remembers to scale to the proper 'incorrect' size, the converted colormap comes out alright.

anyway, please do carry on; we're counting on you! ;) :)

- aqaraza

Joe Sulewski   (Nov 30, 2004 at 13:22 GMT)

Heath,

I have the exporter so that it exports just a texture and the objects. In regards to the accuracy of the mapping you can rotate the textures but you can't scale or shift them. I didn't read your paragraph closely but my long turn solution is to bring JQT up to spec. JQT is an old java based map editor. There are some things that it needs to be really useful but I think it will work better then blender.

Rick Kelley   (Nov 30, 2004 at 15:52 GMT)

Hi everyone, good to see that is alive and well :D I finnaly gave up on precision for the generic map exporter for Milkshape, and just put the texture at a scale of one and to face the way of the plane of the face with a routine found in what is known as zoners half life tools for compiling the MAP format to bsp. I never did get any answers from any of the gurus out there that had working versions of directly exporting a polygon soup model, (tris, not quads, like you can have in MAX and Milkshape), as it seems to be rather a well kept secret. I know of 2 different fellows that programmed a plugin for gameSpace that works really well to export to a torque map format, and since they are making money from it, they are not willing to share the knowledge either.

After all this rage and ranting :D where can you find this JQT you talk about Joe? It might inspire me to improve my plugin.

Joe Sulewski   (Nov 30, 2004 at 16:11 GMT)

Hi Rick,

Yeah I hate IP cloaking. I understand if people want to keep it secret to make money I just wish they would tell me. Be honest, "I'd like to tell you but this is what's making me money so I'd rather not share it" is all they have to say.

In any case, here is the url. I have it compiled and running but it requires a wad file for textures and it's in AWT which is a terrible GUI.

Here is what I want to do.
1. Add a layer system. This would allow you to add parts to different layers that you can turn on and off to reduce the visual complexity of the scene. Allows you to work on interiors in small chunks.
2. Remove the requirement for WAD files. It would be better to just pick the texture from a GUI tree that displays the contents of a directory.
3. Make it support three panes rather than just one at a time. This way you can see top, bottom and side all at once.

In the long term I would like to make is use jogl for speed but that's down the road.

http://www.aegidian.org/gqt/jqt/

EddieRay   (Nov 30, 2004 at 16:21 GMT)   Resource Rating: 4

Well, I hope we can still come up with a good way to convert UV's to ST's... then we can put our results here. This issue has been sitting in the back of my mind... lurking... ;-)

Heath Rezabek   (Nov 30, 2004 at 16:21 GMT)

well heck, i didn't even know JQT existed! :) i will just have to give that a try in the meantime,and watch for your work. thanks. -heath

Joe Sulewski   (Nov 30, 2004 at 16:27 GMT)

Ed,

I tried the code from the maxtomap exporter as you suggested. But it didn't seem to work. It could be that I'm really new to Python and I don't have great tools for debugging or that the code is wrong. I ran through the code I ported pretty well and I'm of the opinion it doesn't work. If someone can verify that the max2map code works then I will re open the approach.

Another problem to consider is that when creating maps you really want your brushes to align perfectly with no overlap. I found this difficult to do in blender even with snap to grid on. There are errors in the editor I believe that show overlap when it doesn't exist and so you end up breaking things because you think it's wrong. Another problem is that there doesn't seem to be an easy way to deal with lights and other entities as Scott Coursey found out. I guess we could right a map parser for the entities but that seems like too much work. I think it would be better to follow the jqt route.

Any opinions would be greatly appreciated. Now if only I knew how to get in touch with the author of JQT to make sure he doesn't mind.
Edited on Nov 30, 2004 16:28 GMT

Heath Rezabek   (Nov 30, 2004 at 21:44 GMT)

Joe - i was surprised to find that JQT needed to run as a Classic app. i have a pretty minimal Classic install nowadays so it never ended up launching.

you know, to play devil's advocate for Blender just one last time... the flexibility and openness of this app really does impress me, and i guess i sure wish there were a way to make it work. i presume you have tried discussing the issues yr having over on the open Blender forums? because they have a voracious and helpful user community, and it wld seem to be that many of them wld jump at the chance to help out in building just such a map editor with you, or answering yr questions. since many Mac users are going to be using Blender as their main 3d editor [i know i am; i sure can't afford Maya etc], it'd be an absolute coup to see a map editor truly integrated using it. it even occurs to me that some of the LogicBricks might be able to be ported as map objects with special properties [door triggers, etc]!

i wld at least try out your questions on the forum; you may be surprised...?

http://www.elysiun.com/forum/index.php
http://www.elysiun.com/forum/viewforum.php?f=5
^^^ the Blender & Python sub-forum...

now that i've made my pitch for not giving up on Blender, i'll step aside and wait; eventually at least i look fwd to using JQT someday, if not Blender. thanks for all you do! :)

- heath

Heath Rezabek   (Nov 30, 2004 at 21:56 GMT)

[or, you cld at least donate what you've done so far with the Blender converter to the Blender community, and let someone else fix it up someday. i'd just hate to see that work go to waste.. i'll shaddup now. ;) :) - h

Joe Sulewski   (Nov 30, 2004 at 21:59 GMT)

Heath,
Your right about Blender being a fantastic product. I really like it and it's my first choice. I've asked some questions on the forums and never got a response. It's easy to get responses to how to do things artistically or simple programming questions. But I can't find anyone able to tell me how to convert UV coordinates to ST coordinates. Perhaps it's not a programming thing, perhaps it's a matter of doing textures differently. The problem I'm running into is how to map textures not to the object coordinates but to the world coordinates.

Imagine plopping two floors down but with a gap between them. If you can tell me how to map the same texture on the floors in such a manner that the gap looks like a missing piece where if it were filled in the texture would be seamless then there is no issue with textures. Tell me how you do it and I'll figure out how to extract the info.

You can't use the logic bricks for some reason. Scott Coursey tried that path and ran into problems. He also posted to the forums about being able to apply attributes to objects without using the game portion and there was resistant response if I remember correctly. But I don't want to quote Scott so take what I say with a grain of salt.

In regards to JQT you don't need Classic mode. It's a java app it runs natively. It's an old web site so ignore the stuff about mrj.

Let me know if that paragraph about mapping makes sense to you I'm sure I'm explaining it terribly. I'm hungry and my family is waiting for me for dinner. :)

Joe Sulewski   (Nov 30, 2004 at 22:00 GMT)

Please don't shaddup. I like the enthusiasm. Let's work together to achieve what we want. Shadow dragon is also trying to help by answer questions about how blender works. One of my problems is that I'm a complete noob when it comes to blender. I really like it but I haven't had enough time to mess with it.

Heath Rezabek   (Dec 01, 2004 at 01:36 GMT)

to be honest, i am just getting started with Blender too. what i wld recommend, if you do not yet have it, is to get a copy of the Official Blender 2.3 Guide by Ton Roosendaal, Stefano Selleri (Editor). i am working my way through it now to get a handle on things. it's so hard to get used to the interface that its learning curve seems very steep.

also, perhaps if it were turned into a Torque community barnraising, things might come of it too. you might scan through those users who were enthused in their responses to the exporter scripts being made;

http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=4662

and perhaps start a 'base of operations' thread on the Torque forums, to corral more hands and eyes. that'd save the load on your .plan page too... :)

i will ponder the textures. is there a way to get ahold of the Blender / Torque tool as it currently stands? glad you like my enthusiasm; sometimes it's almost all i have to offer... :( ;)

- heath

Heath Rezabek   (Dec 01, 2004 at 02:02 GMT)

Joe [& other Blender / Torque'ers] - see this thread over on the Blender forum; scan to the bottom for my post. if the originator cannot get here, that may be a place to post too. earlier responses to his enthusiasm have some of the Blender-ism you speak of, but i'm trying to present the case that crossover is good for everyone. it might be a good place / thread to attempt to ask questions as well. i can watch for Torque'ers and chime in if Blender'ism becomes a prob.

http://www.elysiun.com/forum/viewtopic.php?p=324731#324731
elYsiun.com Forum Index -> Blender Game Engine -> TORQUE!

- heath

Joe Sulewski   (Dec 01, 2004 at 02:11 GMT)

If anybody wants the exporter just e-mail me and I'll fire it over to you.

Richard   (Dec 21, 2004 at 20:05 GMT)

Whoa !
Now I'm enthusiastic once again ! Looking forward to this development !

Marcel Vijfwinkel   (Feb 05, 2005 at 20:03 GMT)

Here is how I calculate the texture vectors, scale and offset in my exporter from Maya to Hammer (Half Life 2). It's in Maya's MEL script, but it should be easy enough to port. Many thanks go to DarthPingu on the Chaosengine for his patient help :)

//
// Calculate Texture vectors
// Thanks to DarthPingu on The Chaosengine!
//

// Express 3 positions as 2 vectors from the 1st point
vector $v1 = <<$XPosition[1], $YPosition[1], $ZPosition[1]>> - <<$XPosition[0], $YPosition[0], $ZPosition[0]>>;
vector $v2 = <<$XPosition[2], $YPosition[2], $ZPosition[2]>> - <<$XPosition[0], $YPosition[0], $ZPosition[0]>>;

// Express 3 texcoords as 2 vectors from the 1st texcoord
vector $tex1 = <<$UCoord[1], $VCoord[1], 0>> - <<$UCoord[0], $VCoord[0], 0>>;
vector $tex2 = <<$UCoord[2], $VCoord[2], 0>> - <<$UCoord[0], $VCoord[0], 0>>;

// Initialise tangent & bitangent vectors
vector $edge1 = <<0,0,0>>;
vector $edge2 = <<0,0,0>>;
vector $normal = <<0,0,0>>;
float $tx,$ty,$tz,$btx,$bty,$btz;

// Find the tangent & bitangent x components
$edge1 = << $v1.x, $tex1.x, $tex1.y >>;
$edge2 = << $v2.x, $tex2.x, $tex2.y >>;
$normal = cross($edge1, $edge2);

if(abs($normal.x) > 1e-7)
{
$tx = -$normal.y / $normal.x;
$btx = -$normal.z / $normal.x;
}

// Find the tangent & bitangent y components
$edge1 = << $v1.y, $tex1.x, $tex1.y >>;
$edge2 = << $v2.y, $tex2.x, $tex2.y >>;
$normal = cross($edge1, $edge2);

if(abs($normal.x) > 1e-7)
{
$ty = -$normal.y / $normal.x;
$bty = -$normal.z / $normal.x;
}

// Find the tangent & bitangent z components
$edge1 = << $v1.z, $tex1.x, $tex1.y >>;
$edge2 = << $v2.z, $tex2.x, $tex2.y >>;
$normal = cross($edge1, $edge2);

if(abs($normal.x) > 1e-7)
{
$tz = -$normal.y / $normal.x;
$btz = -$normal.z / $normal.x;
}

// Load results in vectors
vector $texturevectorU = <<$tx,$ty,$tz>>;
vector $texturevectorV = <<$btx,$bty,$btz>>;


//
// Scale
//

// Calculate the lengths of the texture vectors
float $ul = sqrt( dot($texturevectorU, $texturevectorU) );
float $vl = sqrt( dot($texturevectorV, $texturevectorV) );

// calculate scales (textureUSize and textureVSize are the size of the texture in pixels)
float $uscale = (($ul / $textureUSize) * $globalscalefactor );
float $vscale = (($vl / $textureVSize) * $globalscalefactor );

//
// Offset
//

// normalize texture vectors
$texturevectorU = `unit $texturevectorU`;
$texturevectorV = `unit $texturevectorV`;

// calculate the offset
float $offsetu = $UCoord[0] - (dot( $texturevectorU, <<$XPosition[0], $YPosition[0], $ZPosition[0]>>)/$ul);
float $offsetv = $VCoord[0] - (dot( $texturevectorV, <<$XPosition[0], $YPosition[0], $ZPosition[0]>>)/$vl);

$offsetu = $offsetu * $textureUSize;
$offsetv = $offsetv * $textureVSize;

// Wrap the texture offset
int $tt = ($offsetu / $textureUSize);
int $ss = ($offsetv / $textureVSize);
// substract the repeating part
$offsetu = $offsetu - ($tt * $textureUSize);
$offsetv = $offsetv - ($ss * $textureVSize);


//
// Rotation (Not sure if this is correct, it's just a UI thing in Hammer and has no influence on the texture placement)
//

// vector v1 is the vector of two points in the plane
// texturevectorU has the rotation applied
float $rotangleU = angle($v1, $texturevectorU);
float $rot = $rotangleU * (180 / 3.14159265);



Hope it helps!

Marcel Vijfwinkel

Benoit Touchette   (Feb 06, 2005 at 13:13 GMT)

I am working with Joe on the exporter and i have a quick question, what does $globalscalefactor correspond to?

Marcel Vijfwinkel   (Feb 06, 2005 at 20:03 GMT)

Oops! Sorry, I should have remove that :) The globalscale factor just scales the positions and the texture values a hundred times. This is because it is very hard to work in such a big scale in Maya, so I scale everything when exporting.

Benoit Touchette   (Feb 06, 2005 at 20:34 GMT)

thanks for the update, will see how to integrate some of what i see here into the exporter, i already see a couple of fixes i can apply to the script i am working on.

Benoit Touchette   (Feb 08, 2005 at 19:30 GMT)

Edited on Feb 09, 2005 02:28 GMT

Benoit Touchette   (Feb 09, 2005 at 02:27 GMT)

Btw marcel thanks again, i ended up scrapping my work for an implementation of what you posted and it works even better than i had hoped. So thanks to you and whoever Darkpingu is :)
Edited on Feb 09, 2005 02:29 GMT

Marcel Vijfwinkel   (Feb 09, 2005 at 13:26 GMT)

Ofcourse you can use the code, else I wouldn't have posted it in the first place. Your thread has helped me a lot when I was trying to find out how to calculate the texture vectors, so I am happy I can help back. It would be nice if you could credit DarthPingu in your sourcecode, he deserves some myth-building because he really helped me out a lot on this :)

Did you check if the rotation value is correct? I'm still not sure about it...

Benoit Touchette   (Feb 10, 2005 at 00:34 GMT)

Thanks, my code took a slightly different to get to the same point. Yours was more esthetic pleasing and more functional :)

Sure for the credits go where they are due.

As for the rotation not yet, since it has no inherent value for now. Once thing i did notice last night was those darn floating points, i need to see where i can clamp down on them a bit.

At any rate you can follow my progress at www.draekko.org

Matthew Langley   (Feb 11, 2005 at 22:04 GMT)

blender -> map... very cool idea

Rick Kelley   (Feb 21, 2005 at 18:13 GMT)

Well this has proved to be a very interesting experience, and I think that I have come a long way in understanding the cryptic way that the MAP format has come to a marriage alliance with the CSG and BSP usage :D

I succefully coded my old Generic MAP exporter for Milkshape 3D to work on rotations for the texture by carefully looking over the maya exporter code by Marcel Vijfwinkel and the use of the code of DarthPingu. Of course MEL script and the information of how Maya works had to be transelated, got me to rework my code that was mostly working, but not quite right from the Valve SDK and Zoners Half Life compile tools. It helped to fill in the gaps! I have some more testing on other shapes, but I think it will go well and soon be ready for release. Thanks bunches guys for posting your work!

Here is a screen shot with the top in Milkshape 3D and the bottom in the Hammer edition of the Valve bsp editor:
http://www.drawcad.com/3d/ms3dMAPtest.jpg
Edited on Feb 21, 2005 18:18 GMT

Marcel Vijfwinkel   (Feb 22, 2005 at 11:52 GMT)

When testing keep in mind that the mapping needs to be absolutely planar if you want texture coordinates to be correct. Lets say you make a cylinder and rotate the UV's 15 degrees, this can already mean that the UV's are not planar anymore and your export will have broken texture alignment. It's truly quite tricky...

You can easily check if a face is planar mapped by calculating the angle between the two texture vectors, if they are not (within a small margin of ) 90 degrees then the mapping is non-planar.

EddieRay   (Feb 22, 2005 at 16:34 GMT)   Resource Rating: 4

From what I can tell, "planar" (or "orthogonality") is not a requirement, per se, for the S and T vectors. The solution to the "convert UV coords to S/T vectors" problem is certainly easier to solve if you assume that S and T are orthogonal and "in the plane" of the face, but I'm not convinced that will provide enough flexibility to convert common UV mappings like a basic rectangle, that has U going from 0 to 1 in one direction, V going from 0 to 1 in the other, but the V = 1 edge is shortened (with U still going from 0 to 1 along that edge) and/or sheared. I think this kind of mapping is possible with S and T vectors, but not if you assume they are orthogonal...
Edited on Feb 22, 2005 16:34 GMT

EddieRay   (Feb 22, 2005 at 16:37 GMT)   Resource Rating: 4

By the way Benoit... thanks for all the hard work on this! When I get a chance to get up to speed with Blender, hopefully, I'll be able to contribute something more "substantial"... ;-)

Benoit Touchette   (Feb 22, 2005 at 21:06 GMT)

Ed: No problem all help/suggestions is/are welcome. Right now i am working out how to do a dynamic UI for the other parts (ie, lights,portals,etc...).

Rick Kelley   (Feb 25, 2005 at 16:41 GMT)

Now that my plugin for MS3D seems to be mostly working, I tried out some architech that has arches, and tube type of brushes. The results worked on some things, on others I had some weird output. When I looked at the resulting MAP text, it seems the scale was set to 0 and some of the texture axis had some odd values. I guess its back to the drawing board...

Rick Kelley   (Feb 25, 2005 at 16:53 GMT)

btw, Ed I am begining to think that the problem may lie in the conversion of UV to ST as you have been stating. If I set the texture as a 256x256 image size and keep it ortho, everything seems to work correctly. But if you start to use an odd shape of a quad type of area, then this is where the stuff hits the fan! See the image link to see what I maen when I tried some cylinders, and even triangular shapes for a wall that had an archway in it. The scales sometimes went wild, and on the other side of the wall, they were calculated as being 0, and sometimes the axis were all 0 lengths.
http://www.drawcad.com/3d/non-ortho.jpg
Edited on Feb 25, 2005 17:08 GMT

EddieRay   (Feb 25, 2005 at 19:06 GMT)   Resource Rating: 4

What part of the image are you referring to... the walls around the arch, that have plain blue and plain green color (when they should be the same image as the boxes - with colors and numbers 1,2,3,4)?

EddieRay   (Feb 25, 2005 at 19:11 GMT)   Resource Rating: 4

Maybe we should move this discussion to a forum thread? Joe hasn't commented in some time... and this is his "plan"... ;-)

Joe Sulewski   (Feb 25, 2005 at 19:18 GMT)

First let me apologize for not commenting. I've been so busy lately but I have free time as of next week. I would love to get back into the mix with you guys.

This is a key thing for me to get working. Again, I apologize for not replying to any of this. I should be able to add more next week.

Joe Sulewski   (Feb 25, 2005 at 19:22 GMT)

So in short feel free to keep this here or a forum, no matter to me.

EddieRay   (Feb 25, 2005 at 20:04 GMT)   Resource Rating: 4

No problem Joe... just didn't want to munge-up your .plan if you had moved on... ;-)

Rick Kelley   (Feb 26, 2005 at 06:03 GMT)

The original model from which this was created, had the UVs mapped like in this image within MS3D:
http://www.drawcad.com/3d/ms3d-map.jpg
I have even scaled other 256x256 image corectly on other objects, but whenever the shape is not
a rectangle in some form, then problems start happening.

EddieRay   (Feb 26, 2005 at 18:04 GMT)   Resource Rating: 4

Yeah... that's what I was thinking it should look like... :-(

Rick Kelley   (Mar 09, 2005 at 16:43 GMT)

Ok, I got back to looking over the code, rewriting it and then scratching it completely, going back to my old code based on zoners half life compile tools, scratching that, scratchint my butt, etc. and coming up with this thought on the matter:

My code that I reworked from zoners will determine the area the texture axis needs to point, but not how the axis should be rotated. The code provided from the Maya script, will determine how the axis should be rotated, and point if the brush is cubical. or form a rectangular shape with the texture applied being a stretched onto the rectangle. If you try to offset or scale this texture, (which by the way up until now I have used a 256 x 256 texture), or rotate it in the modeler known as MS3D, will screw the living heck out of it and will not work. This is apparent in my images that I have links for in this plan above.

So from the rantings above, the maya export code seems to get screwed because it is not correctly getting the texture axis direction, which could be because of common vector errors of not compensating for opposites. (Your going to have to pull out books on this one). This is why Half Life came up with the best_texture_axis bit of code:
static const vec3_t s_baseaxis[18] = {
{0, 0, 1}, {1, 0, 0}, {0, -1, 0}, // floor
{0, 0, -1}, {1, 0, 0}, {0, -1, 0}, // ceiling
{1, 0, 0}, {0, 1, 0}, {0, 0, -1}, // west wall
{-1, 0, 0}, {0, 1, 0}, {0, 0, -1}, // east wall
{0, 1, 0}, {1, 0, 0}, {0, 0, -1}, // south wall
{0, -1, 0}, {1, 0, 0}, {0, 0, -1}, // north wall
};

// =====================================================================================
// TextureAxisFromPlane
// =====================================================================================
void TextureAxisFromPlane(plane_t* pln, vec3_t xv, vec3_t yv)
{
int bestaxis;
vec_t dot, best;
int i;

best = 0;
bestaxis = 0;

for (i = 0; i < 6; i++)
{
dot = DotProduct(pln->normal, s_baseaxis[i * 3]);
if (dot > best)
{
best = dot;
bestaxis = i;
}
}

VectorCopy(s_baseaxis[bestaxis * 3 + 1], xv);
VectorCopy(s_baseaxis[bestaxis * 3 + 2], yv);
}

The problem here is to figure out how to use this information and to tweak it after it has figured out the actual direction and to futher massage it to apply correct normals for the tuplets that lie between -1 to +1.

This is where I am at right now/

Joe Sulewski   (Mar 09, 2005 at 18:19 GMT)

Well it appears that garage games is releasing a map editor. It would have been nice if they told us about this before hand. I believe I e-mailed GG if they were doing this because i didn't want to waist my time and I got no response.

http://www.garagegames.com/news/7317
Edited on Mar 09, 2005 18:20 GMT

EddieRay   (Apr 26, 2005 at 21:55 GMT)   Resource Rating: 4

Actually, I think the GG-blessed map editor could be a bad idea... especially if the source is not made available to customers. The main problem I've seen with map editors is that, like Quark, they just don't fit everyone's style and workflow expectations (and most are downright idiotic, if ya ask me). IMHO, what the TGE community needs is a completely open and free map editor, that can be scrutinized by many people for ease-of-use, sensible and useful workflow, and can be altered by people as they see fit. Not sure why noone has started such a project yet... but maybe if Constructor turns out to be more of the "Hammer/Quark/CShop is much less than I expected" kinda thing... who knows.

That said, Benoit... if you're still watching this thread, I'd be happy to test your Blender->.MAP exporter if you're still looking for testers. I'm a little off my game with Blender at the moment, but I'll struggle through. I'd also like to get familiar with how to right an exporter for Blender anyway...

Richard   (Apr 28, 2005 at 20:34 GMT)

Joe,

.. if you're still here-abouts, I agree with EddieRay; the thought of abandoning the project on the premise that another group is doing something similar .. well, it just doesn't sit right with me.

The aim from here should then include making a superior end product that is not only open-source, but will out-play, out perform ... Hey ( ! ) wait a min .. this sounds familiar :o)

..you get the drift.

Joe Sulewski   (Apr 28, 2005 at 20:51 GMT)

Hi Guys,

I'm still here and I've been meaning to respond but I've been busy with work, sorry about that. Working on it right now is not a priority for me as I can use Radiant on the Mac (I'm not ready for commercial production yet so the license doesn't bother me). However, when I am ready to make something commercial then the need for a less restrictive map making tool will become important.

In regards to the exporter I came very close to getting it to work but the stupid offsets killed me. Then Benoit stepped in and tried going at it from a different direction and I think he ended at the same spot, not quite sure you'll have to ask him.

Anyway, I know nothing about Torque Constructor so it's too early for me to assume that it will be like Quark and the others. Hopefully it will have the ability to be extended through torque script. I would suggest finding out more about constructor before we rack our brains on a blender exporter.

What do you think?

Joe

EddieRay   (Apr 28, 2005 at 20:53 GMT)   Resource Rating: 4

@Richard: Good to see another lurker... ;-)

@Rick: I thought I had already commented on your code... but evidentally not. I've seen similar code before somewhere... maybe in the CShop .MAP exporter code.

The trick is to take the 3 component's that of the "best axes" and use that as the 3 components of S and T... pretty straightforward... except for what to set Sw and Tw to... I think they get set to either 1.0 or 0.0. You end up with a .MAP file that has lots of 1.0s and 0.0s in the S/T components. This has the effect of "projecting" the textures onto surfaces in one of the normal X/Y/Z axis directions.

But this avoids the whole converting-UVs-to-ST-vectors problem altogether, and a map-editor program will typically just work completely using ST style mapping, and convert to UVs only for it's display code.

Using the "best axis" method provides a pretty basic mapping capability. It doesn't suit complex mesh shapes very well though... for that, you need to compute ST vectors that aren't parallel to the world X/Y/Z axes, but are actually aligned to the face that's being mapped, or even rotated "out of the plane" of the face being mapped, to give stretched/squashed mappings. Then, there's nothing to say the S and T vectors need to be orthogonal (at 90 degrees to each other and in the same plane)...

Anyway... I'm out of time right now, but let's get this conversation fired up again... :-)

EddieRay   (Apr 28, 2005 at 21:17 GMT)   Resource Rating: 4

@Joe: Hey, we actually crossed posts on this thread! Wow, what are the odds? :-)

Personally, I think the Blender .MAP exporter would be a great learning experience to continue on with. If for nothing else than to see a real effort fully documented with all our findings. If it were easy, there would already be scads of documentation out there on the texture mapping issues we've been discussing at length so far. There are really only two "big" issues AFAICT in making a decent .MAP exporter:

1) Either converting straight UVs to ST-style mapping using the exporter code, or making the editor (Blender) support ST-style mapping. It would at least be possible to just *define* what kinds of UV mappings are easily converted to ST mappings and then figure out ways to adhere to them while using Blender so that the export process will work as expected.

2) Convex geometry. Should an attempt be made to convert concave meshes into convex pieces automatically?

It'd be nice to be able to support entities for light placement, etc. And it'd be nice to have the exporter automatically run Map2Dif for you, gather up the output, and display it to the user, etc.

Ed

Joe Sulewski   (Apr 29, 2005 at 17:56 GMT)

Ed,

I responded to this yesterday, I wonder what happened to the post?

In regards to 1 Blender does, I believe, support ST mapping. You can setup textures to map to world coordinates. The bad part is that the settings are not available to Python. So close, yet so far. :(

In regards to number 2, slicing and dicing is tricky and may yield results the artist doesn't want. I would rather just highlight the offending objects.

Finally, it's possible that the new map2dif will work with UV's. That would make it easier as well.

Here is an interesting link. This guy is working on a blender import/exporter for quake bsp.

http://67.22.114.230:8082/programming/blender/
Edited on Apr 29, 2005 17:56 GMT

EddieRay   (Apr 29, 2005 at 18:59 GMT)   Resource Rating: 4

Quote:

---

I responded to this yesterday, I wonder what happened to the post?

---

Yeah... sometimes I click "Post Comment" and my post just disappears into the bit bucket... not sure what's happening with that. It's frustrating for posts I spent an hour typing and thinking about. I've started copying to the clipboard before clicking that dreaded button... ;-)

Quote:

---

Blender does, I believe, support ST mapping.

---

Hmmmm... didn't know that. How do I access that feature?

Quote:

---

slicing and dicing is tricky and may yield results the artist doesn't want

---

I agree. But I do believe it's unnecessary to require only convex geometry. I think the best solution is to have the exporter automatically slice and dice things and report when it can't do it with existing vertices. For example, a box object that has a smaller box extruding out one face - the exporter can easily slice that geometry without causing any problems because the big face is planar with the vertices of the smaller face (and vice-versa). Little "allowances" like this can be a big win IMO...

Quote:

---

it's possible that the new map2dif will work with UV's

---

Really? I hadn't heard that. I *have* considered hacking the small portion of the Interior rendering code to allow UVs to be used, but I haven't actually tried to do it yet. I was thinking that the Sw or Tw value could be used as a flag to the rendering code to say "S and T are really a set of 3 UVs for the face - just use them instead of computing UVs". Might be interesting to try. I noticed from looking at the rendering code that the lightmaps generated by map2dif actually use UV coords (no ST stuff at all). It seems like the ST mapping is really just there for historical reasons... and since STs are easily converted to UVs, but not the other way around, the mapping tool should be where STs are used, and the rest of the pipeline should just use UVs...
Edited on Apr 29, 2005 19:00 GMT

EddieRay   (Apr 29, 2005 at 19:06 GMT)   Resource Rating: 4

Regarding the "new map2dif"... what are you referring to? There's a new map2dif...?

Joe Sulewski   (Apr 29, 2005 at 19:16 GMT)

Ed,

The feature for Mapping to world coordinates is in the "map to" button in the material editor. You don't use the UV stuff at all. You create a texture then assign it to each face and use the mapto buttons in the material editor. The texture editor (located as a tab in the material editor) has buttons for repeat and offset. It sucks because I can see the solution but it's out of reach. I feel like the town drunk in jail in a western movie. I can see the keys to the jail cell on the wall but I can't quite reach it.

You bring up a good point about the slicing and dicing. In fact it may fix a problem that blender can't easily fix. Aligning objects up so that they butt perfectly isn't easily accomplished. But then again, doesn't map2dif slice and dice?

I believe that the map2dif compiler converts the ST's to UV's and the system uses UV's from then on in. I think ST's are used to make it easier for mappers because you don't have to worry about making the floor/wall/ceiling textures seem together.

Joe Sulewski   (Apr 29, 2005 at 19:17 GMT)

Oh yeah, in regards to the UV's being supported by the new map2dif I thought I read that somewhere. But it's so fuzzy in my head it may just be a dream I had. We should check with Matt Fairfax.

Joe Sulewski   (Apr 29, 2005 at 19:19 GMT)

Mattew Fairfax is writing a new map2dif compiler.

EddieRay   (Apr 29, 2005 at 19:40 GMT)   Resource Rating: 4

New map2dif: Okay... I tried to send Matt a note, but he hasn't answered me. Probably because I was asking to help beta test Constructor... DOH!

STs in Blender: Okay... I'll have to try that. I'm a bit fuzzy on materials and texture mapping in Blender still... ;-) So you can't get at those ST variables with Python? Hmmmm... seems like it should just be one of the many material properties. I'll have to try it out to see how it works...

map2dif slicing for you: I don't think so... but I haven't tried it... hmmmm...

map2dif using UVs: From the Interior rendering code, it is converting the STs to UVs at the very last moment as it fills the vertex buffers before passing them to be rendered in OpenGL. I'm pretty sure the STs are all that is used (except for the lightmaps as I mentioned) in the code up to that point, and in map2dif.

floor/wall/ceiling mapping: Sure... that's handy. But it's not really necessary to use STs to do that sort of thing... and while it's good for floor/wall/ceiling mapping... it's pretty yucky for other things like cylinders or things that need to be "wrapped" with texture... ;-)

Rick Kelley   (May 05, 2005 at 20:06 GMT)

Well its good to see everyone back at the drawing board. Actually Ed, in regards to the alignment of the above code that I posted that came from zoners half life code for handling compiling of maps, I can have irregular shapes mapped just fine with it. I am hung up on how to get the proper scale. From what I can see of this bit of code, Valve used it for the WorldCraft editor for levels to figure out the best axis and then used other code to figure out how to scale, and rotate it properly on the brush. What is going on is that it tries to find the "center" of the UV and use this as top left corner to place the image. Other magic numbers are applied to figure out the scale and rotation, and these are computed into a range of -1 to +1 range for the tuplets. If you were to leave the set of best texture axis function alone, then the texture will align unrotated, and unscaled in both the x and y directions to the face of the brush. I havent noticed any stretching of the texture using the above method using unothgonal brushes. There was someone that used the zoners half life code for a bases to make a Map Export plugin for what is called gameSpace, and it seems to work perfectly. As to slicing and dicing in the code, this would cause a lot of headaches and perhaps not work well, I say this from experimenting with another Map Exporter plugin that was available for gameSpace that tried doing this. The author finaly stated that it would be best to have the brushes in a nonconcave formation to expect best results. In my exporter readme text I tell the reader to form the brushes in a complete nonconcave fashion, and if they need to make something look complex, to just use more than one brush that has the vertices snapped, but not welded to the other brush object. I have fooled around with a Max Map exporter that broke up each quad face structure into a brush, which is extremely wasteful in level making IMHO as it would cause a huge lag on the game engine trying to render all the brushes in a complex shape.

EddieRay   (May 05, 2005 at 20:57 GMT)   Resource Rating: 4

Hey Rick... which MAP exporter are you talking about for gameSpace?

One problem withe "best axis" solution is that cylinders don't get mapped as you would like, i.e., with the texture-map "wrapped around" the round surface of the cylinder.

I guess I'm gonna have to come up with a test program to play with ST mapping and the conversion to UV mapping side by side... not sure when I'll get the time tho'.

Joe Sulewski   (May 05, 2005 at 21:02 GMT)

Hey guys. I have a thought. Since Blender is in Def-Con 3 perhaps we can collaborate and write letter asking them to give us Python access to the texture materials. Then we don't have to worry about ST-UV converstion. Blender should theoretically give us the ST coordinates, scaling and rotation out of the box with simple Python calls. Now is the time to do it. And if enough of us explain why then perhaps they can make it happen.

What do you think? It's easier then the math. :)

Rick Kelley   (May 06, 2005 at 02:54 GMT)

@Ed it would be "The Mapper" by Aeon Games or Rodirego Hernandez. I saw him on one of the Code forums asking others about WorldCraft map formats. He was directed to this paper done on it by Stefan Hajnoczi called ".MAP files
file format description, algorithms, and code." In the paper, he describes using the zoners half life code. But the paper goes on to describe the reverse of what we are trying to do., recreate the MAP file to polygon soup. If you want to look at this paper, I have it in PDF file format. Rodirego Hernandez seems to have grasped the contents to get it to working. He did post some code in the forum and said that it mostly work to figure out best axis and what follows is his original posting to the forum:
if((fabsf(Normal.x)>fabsf(Normal.y))&&
(fabsf(Normal.x)>fabsf(Normal.z)))
{
vUNormal.x=0;
vUNormal.y=1;
vUNormal.z=0;
vVNormal.x=0;
vVNormal.y=0;
vVNormal.z=-1;
}
else if((fabsf(Normal.y)>fabsf(Normal.x))&&
(fabsf(Normal.y)>fabsf(Normal.z)))
{
vUNormal.x=1;
vUNormal.y=0;
vUNormal.z=0;
vVNormal.x=0;
vVNormal.y=0;
vVNormal.z=-1;
}
else
{
vUNormal.x=1;
vUNormal.y=0;
vUNormal.z=0;
vVNormal.x=0;
vVNormal.y=-1;
vVNormal.z=0;
}


Where Normal is a Vector class (or struct) variable that contains the plane normal, vUNormal is the texture U normal and vVNormal is the V Normal.

Even though this is ok to get the initial (default) values I would still be interested on calculating the actual values given that I have a fully texture mapped cube, I am codding so the user gets to set the values by hand
/////////////////////////////////////////////////////////////////////////////////



After he posted the above code, someone replied to him about fixing it up more in this way:

Maybe this helps. You said they use 5
texture values. OK. You're fully right with the plane stuff. So
take a polygon. Let's say the polygon has four vertices. Now
it's your task to give each vertex a texture coordinate.


In ideal case this would be:
v1(0|0) ^ v2(1|0) ^ v3(1|1) ^ v4(0|1)

These are the texture coordinates for your
polygon. So, now you could rotate them
around you polygon middle. Or you could
scale them in a direction of your choice.

Benoit Touchette   (May 06, 2005 at 13:02 GMT)

If you need most of the .MAP (Quake and others) files doc out there you can find most of them here www.draekko.org/draekko/index.php?d=14&m=04&y=05&category=2

EddieRay   (May 06, 2005 at 15:46 GMT)   Resource Rating: 4

Thanks Benoit... I think I already grabbed most of those a while back (if not all of 'em)... ;-)

EddieRay   (May 06, 2005 at 16:22 GMT)   Resource Rating: 4

@Rick: Yeah, I've seen code like that for choosing the axes that S and T will use. Again, it's pretty simple to just do mappings along the coordinate axes, but a modeller doesn't do that normally. I tried to play with Blender to use "Global" texture coordinates, but I'm a bit unlearned with that aspect of Blender so far, so not much luck yet. (Can Blender display textures in real-time? Setting the mode to "Textured" for me doesn't seem to actually do the job, but an F12 render will show the textures). For gameSpace, the "Level Exporter" product includes a plugin called "gameUVs" which basically computes the UVs for your object(s) whenever you click it, based on world coordnates, the material settings for U repeats and V repeats, etc. So it bypasses the whole "convert UV to ST" issue altogether.

Ideally, I think the solution is to figure out how to compute the S and T vectors to best simulate the UV mapping. AFAICT, it a matter of solving the following two equations correctly for Sx,y,z,w and Tx,y,z,w:

U = Sx * x + Sy * y + Sz * z + Sw
V = Tx * x + Ty * y + Tz * z + Tw

So that's 6 equations right there, since we have 3 vertices that all use the same S and T vectors:

U1 = Sx * x1 + Sy * y1 + Sz * z1 + Sw
V1 = Tx * x1 + Ty * y1 + Tz * z1 + Tw
U1 = Sx * x2 + ...
V2 = Tx * x2 + ...
U3 = Sx * x3 + ...
V3 = Tx * x3 + ...

... we need 2 more equations. In max2map, the code around line 513 in main.cc appears (although I'm not completely sure) to compute the face normal (based on the vertex locations) and incorporate it into the matrix that will be inverted to find the solution. That's the "fuzzy" part to figure out... which I still haven't done yet. ;-)

Rick Kelley   (May 06, 2005 at 20:28 GMT)

I am not sure how blender goes about giving up the texture information. In MS3D it will give you the UVs directly with a function:
msVertex_GetTexCoords (pVertex, uv);
so for what its worth, I dont have to compute the S and T. My problem lies with the correct computation of the
tuplet pairs in the range of -1 to +1 which looks a lot like a normal vector + some scaling information. This is where Joe has had his problems as well.

EddieRay   (May 06, 2005 at 20:47 GMT)   Resource Rating: 4

I think you can get at the UVs in python in Blender, but someone said you can't access data for the other method (called "Global" mode or something - basically, uses world coordinates to map textures). I haven't tried personally...

Eventually, if you want to make a .MAP file, you have to compute the S and T vectors (the "texture coordinates" or "texgens" that are needed with every "brush" you put in the .MAP file to describe the texture-mapping for each face). Either the map-editor/modeller supports texture-mapping via S-T vectors, or via UV mapping. If it uses UV mapping, you have to use some method to convert the UV coords for a face into S and T vectors for the face, because when your object gets rendered in TGE, the above two equations are used to map convert S and T vectors back into UV coordinates. It seems kinda silly to have to use S and T at all, if you really just need UVs for rendering the final results, but that's the whole issue... the mapping tools use S and T vectors and the MAP format only supports S and T vectors.

Tom   (Sep 12, 2005 at 20:32 GMT)

so, Joe Sulewski

i was just wondering if it would be possible for me to get that blender to map exporter script.

i enjoy blender (and already use it for the dts and dqs files) and it would be great if i could also use it to create the ,map and .dif files for torque.

Markus Karlsson   (Jan 10, 2006 at 12:23 GMT)

Anything happening on this plan? I for one would rather use blender over quark any ol' day of the week! Cheers!

You must be a member and be logged in to either append comments or rate this resource.

Home | Products | Solutions | Downloads | Support | Search | About Us
Copyright © GarageGames.com 2000 - 2009 All Rights Reserved