Problems with brush definition in blender and input in UFORadiant

[mameister]

Hi guys,

this is not supposed to be a rant or something, I just stumbled onto something:

a) I am a complete idiot (so it seems) in using the vertex and edge tools in UFO Radiant. Meaning: I cannot get the shapes I want, because UFORadiant sometimes decides to translate a vertex or edge along that I did not intend to transform

b) I am quite used to blendering, so I thought: why not use the excellent blender exporter (called "Quake3 *.map"). All that this thing does is to notice what actually a cube is and then to output this into the half-plane definition of the brush format ala .map

c) I am successful with "simple" map scenes and I do know the scaling issue and grid quantization.

OK. Now: If you look at the below two pictures: I am quite at a loss to understand, why this does not work. Any ideas? Where am I going wrong?


Thanks,
Martin

[mameister]

just to show that it does work, when untransformed

[H-Hour]

I have tried using the exporter and found it mis-translates vertices all over the place. I agree, it would be fabulous to have some kind of Blender support, but I haven't yet found anything that works.

If you've got the patience, please keep trying. Finding a working exporter could be invaluable for the long-term future of UFOAI mapping.

And you're not the only one who has trouble pulling vertices around. UFOAI's engine (and editor) work very differently from mesh-based systems like Blender and 3DSM, in which you can pretty much create any kind of shape you want. With UFORadiant it takes time to learn what kind of transformations you can make with a reasonable amount of work.

One thing you could try (if you want to do terrain like the screenshot), is to build a brush in Radiant and cut it into a triangle. Then you can copy/paste that around until you generate a surface patchwork of triangles. From there you can start to build out shapes more easily, though its tedious working with all those individual verts, because no matter how much you raise or lower a vert, you'll still get a proper triangle.

[mameister]

I find that the file is not at all messed up, coordinate wise (see attachment).

One technicality though about brush definitions:

While I agree that it is all about vertices, it is also about half-spaces, i.e. plane definitions. 6 plane definitions (equations that evaluate to >0 for outside or <0 for inside) make up a hexagonal (cube, bush whatever). Each plane is defined via three vertices in the map file. That is its weakness (and maybe room for extension).

Here is the catch as far as I understood:
- you can of course manipulate your blender cube any way you like
- that does not always leave you with planes since your manipulated four vertices are no longer guaranteed to lie on a plane
- the blender exporter takes (I guess) the first three vertices per quad (since our cube has 6 quad faces)
- our UFORadiant loads three vertices per quad (it cannot do any other since it only has these three per side)
- it sets up a plane equation (presumably) and takes into account the other planes
- the fourth point gets either interpolated along the lines of three other plane equations or some existing point gets taken into account

That's the mess we're in. Nothing to do with coordinates really.  This will sound monstrous probably:

My question is: How hard is it to change the brushes definition to two triangles instead of one? It would break up each quad into two, will leave us with easier phong interpolation, etc.? Probably no longer is a Q2 engine, then

[mameister]

Sorry, forgot the blender file.

[H-Hour]

Not sure if we're misunderstanding each other or if we get different results. This is what your .map file looks when I load it up in UFORadiant.

For the rest, I'm afraid it's above my pay-grade. I know next to nothing about the mathematical details behind how it all gets handled, but if I'm not mistaken everything in q2 gets rendered as triangles.

[Mattn]

we have an exporter in our repository. see src/tools/blender/export_ufoai.py - it might need some updates though.

also have you seen this: http://www.wrwrwr.org/ufoai-blender-map-importer-preview

[mameister]

Oh, a lot to check there. Thanks for the hints. Might follow a different direction though:

My geometry considerations basically say the following:
- Blender lets you model quads which is fine
- Blender does not care if all four points lie on a plane (edit to correct: was "quad")
- the map file for the six sides of a brush (hexagon brush = cube) defines only three points per side.
- this way it is not possible to have "inconsistent" normals across a quad
- UFORadiant seems to force all four vertices to lie on a common plane when transforming which is consistent with the way, hexagons are stored (three points per side = plane)
- UFORadiant has no other choice if a brush will always be defined be
  - six sides
  - three points  ( = one plane ) per side

So, in short: I will never get what I want. But, at least I already have a name for what I want:

-> the dreaded "12 sided hexahedron" (which basically is a cube, where each of the six sides is made up out of two triangles)



Thanks for your comments

[mameister]

Not sure if we're misunderstanding each other or if we get different results. This is what your .map file looks when I load it up in UFORadiant.

For the rest, I'm afraid it's above my pay-grade. I know next to nothing about the mathematical details behind how it all gets handled, but if I'm not mistaken everything in q2 gets rendered as triangles.

Could you attach a screenshot?

[mameister]

OK, I did it, but it is a pain (as expected). What I don't like is, that there is virtually no "phong" roundness effect. But maybe this is due to the less than subtle changes in surface orientation.

Can I change the "smoothing angle" for the phong variable in Radiant?

[H-Hour]

Oops! Was late last night and I was tired. Here's the screenie, although it looks like you made some progress.

Withour engine, Phong is a surface flag that must be applied to the surfaces in UFORadiant. You'll get some rounding effects, but either way you'll find lighting artifacts are frequent with the engine. Try compiling with -quant 3 or -quant 2 (lower = higher quality) to get sharper shadows.

[H-Hour]

Hmm, I haven't tried the exporter mattn mentions. I've only tried the technique described here. Maybe this other exporter will work better.

Would be curious to know your results mameister. Even if you can only build uneven ground like in your screenshot, it will be useful for quickly generating tiles in nature sets.

[mameister]

Well you won't like this, but I did it like this:
- model scene in blender composed from cubes
- triangulate
- re-write exporter to do the most horrible thing: split each cube into 12 (!) tetrahedrons. Bloody hell.
- Exporter writes phong and nodraw flasgs as well as no_draw texture
- Import in Radiant, slow as hell
- Select only the faces you need, deselect nodraw flags, set texture
- compile for a long time
- you are done

My next exporter will definitely be for height maps and prism based.

[mameister]

Prism export for landscapes

- make normal quad or trigrid in blender
- scale to correct size
- import in radiant (nodraw texture and flag and phong flag is set)
- select all
- select all faces (showing upward in this case)
- select texture
- save/compile

Problem: sometimes the texture mapping gets it wrong (see last image)

[H-Hour]

Wow, that's great. I might have to learn how to use Blender! Is this your own exporter or is it available somewhere. Just for the new 2.5 (?) or which versions of Blender?

Problem: sometimes the texture mapping gets it wrong (see last image)

in UFORadiant, when a face has more than a 45 degree angle, it aligns itself along a vertical axis rather than a horizontal axis, and this means that the texture can be rotated 90 degrees different depending on the direction (although both are at their 0 rotation in the surface properties). A bit of minor touchup is all that's involved.