DeleD Community Edition

[Paul-Jan]

Here is an e-mail I got (I cut out the images):

[Paul-Jan]

Our UV Editor is still very barebones, no fancy wrappings yet, so you'll have to do everything by hand. And even that could do with some more convenience tools. These are all things we will improve in the future, but for now, let's do things the old fashioned elaborate way.

Here is the basic pole model we are going to map. I just used a 2 segmented cylinder, pulled up the edge to make the upper segment smaller, then grapped the vertices on the top and scale them together to make the pointy bit.



Now by the looks of it, this model would be a perfect match for a cylindrical mapping. However, DeleD doesn't have a cylindrical maping yet, and the default box mapping will map the sides of the pointy bit to 4 different sides of the box, which is a pain to correct.

Because we don't have the right mapping for the job, we'll work the other way around: let's adapt the model to the mapping first and correct afterwards. Select the vertices of the pointy tip and pull them down to the start of the pointy part, effectively creating a flat cylinder.



Now generate the box mapping (right mouse menu). It's not perfect yet, but at least the pointy part is now a nice circle-shape. In the image below I've drawn some ugly arrows to show where I moved all the different parts.



The sides of the body of the pole are still separate, so we have to manually match them up. To do so, I usually close all viewports but the 3D and UV mapping viewport and make them as large as possible.

We also move the top and bottom (circular parts) to the correct locations and scale them (keep CTRL pressed to keep the aspect ratio fixed) to match up with the texture. The result will look something like this:



Now from the top view, grab the vertices of the tip again and pull them out. The result will be nicely mapped:



You might notice there is still a seam left in the texture map (the left and right sides of the maping of the pole's main body). If you use a texture that nicely repeats from left to right, and scale up the body part mapping to exactly match the width of that subtexture, the seam should practically disappear. For pixel-perfect results you might want to copy a small amount of pixels from the left and add it to the right, so even the texture filtering matches up.

I don't have time for all that now, and my model looks poor anyway because I have no artistic skills whatsoever. Just hope the techniques are clear! If there are any questions, just ask away...

[elementrix]

[Paul-Jan]

Can't be more precise than 'not in the immediate future, but not in the distant future either".

I'm sorry about that, but because of the holiday season and the lack of available manpower we kinda stopped roadmapping beyond our immediate planning, as we can't make realistic guesses anyway. Current planning = getting the 1.71 release out the door somewhere next week.

[TenTerHooK]

Thanks for the help so far. Its been great and my mapping has improved greatly.

But I found some errors when exporting to Torque which is the engine I am using. If I use one texture to map the top and sides of pole the mapping is way of even though it looks fine in deled.

I fixed this by seperating the textures and it worked out fine for the sides of the pole, but the tiling on the top is still of and I have no idea why. It looks fine in deled.





But when I export to Torque the tiling goes bad for some reason.




I dont know if this is map2dif messing things up on me or what... and I was so close!

[Paul-Jan]

Aha, Torque!

The short story: The Torque Exporter is to blame, it doesn't export the texturing properly. We should fix it.

The long story: The .map file format doesn't use UV coordinates, it uses so-called "texture axes" to record the mapping of the texture onto the plane. Which is nice and dandy, but I don't know how to map an arbitrary set of UV coordinates on said texture axes, and I can't seem to find any good information either. I'll see if I can fix things for this specific situation... but if you know any other polygon -> .map/.dif exporter that properly handles UV coordinates properly I might be able to learn from it.

I'll see what I can do, thanks for reporting the problem!

[jwatte]

[Paul-Jan]

*lol* Well, to be honest, this was the first solution I tried, but when
a) It didn't work 100% and
b) I realized I wasn't all that sure that was the way the "texture axis" in the .map format worked anyway (why all the redundancy? There is scale and rotation too, although as I understand it rotation isn't used at all in the Torque setting) and
c) I peaked inside the sources of some other plugin (probably the Blender .map exporter) and a similar solution was commented out for not working...

... I kinda gave up on that route to look for more info. However, if those are indeed the equations (you seem to be pretty sure), I probably just have some errors in my implementation. I'll give it another look. If you are correct, I'll be a very grateful man...

[TenTerHooK]

I personally would really appreciate being able to uv map bsp structures like they where 3d models. Its one of the big limitations on this format in my eyes.

Really lowers the potential with the format.

If anybody knows of a workaround please let me know.

[jwatte]

Well, those are the equations for what "texture axes" usually mean. No idea what perversions they may be using for Torque .map files.

Although I am a Torque licensee, so I can take a look in interiorMap.cc...

OK, the coordinates seem to be in pixels, because the first thing that happens is dividing by texture map size to normalize to 0/1. That's a problem if you want to build with one resolution, but deploy with another.

Then the texgens are scaled by something called "brushscale" in the map format.

Then, the texture coordinate generated is just x*a+y*b+z*c+d for the world-space position. There's a separate texgen, that works the same, for light mapping, too.

In the Valve 220 parser, there is an additional scaling factor which affects a, b, c but not the d term.

Last, make sure you use the same "up" as they do :-) The texture T/V coordinate goes from first byte towards last, but the default JPG/PNG loaders deliver the top scanline first, but the default TGA/BMP loaders deliver the last. You probably have code for this already.

Note: this description goes from the rendering and backwards in the pipe, describing how each intermediary value is determined.

[Daaark]

What is it with Torque and all these funny 'solutions'?
_________________

[trucker2000]

[jwatte]

Up/down doesn't matter to any 6dof engine. The problem with Torque is that it uses the .MAP format, which was written back in the software renderer days, where texgen axes interpolated easier than explicit texture coordinates, and texture coordinates in pixels instead of normalized to 0..1 saved a multiply per texture look-up.

[jwatte]

OK, in PM we figured out what the fourth equation is to make the system fully determined. The U and V coordinates should not vary in the direction of the face normal. Thus, the full solution looks like:

Ax*V1x + Ay*V1y + Az*V1z + Ac = U1
Ax*V2x + Ay*V2y + Az*V2z + Ac = U2
Ax*V3x + Ay*V3y + Az*V3z + Ac = U3
Ax*Nx + Ay*Ny + Az*Nz = 0

Bx*V1x + By*V1y + Bz*V1z + Bc = V1
Bx*V2x + By*V2y + Bz*V2z + Bc = V2
Bx*V3x + By*V3y + Bz*V3z + Bc = V3
Bx*Nx + By*Ny + Bz*Nz = 0

These are now fully determined systems, that only go denormal when the mapping is denormal.

[TenTerHooK]

Does that help with fixing the bad mapping in Torque?

..or is that theoretical..

..sorry.. me no program good.. me program bad.. :/