UFO:Alien Invasion
Development => Mapping => Topic started by: mameister on January 31, 2011, 07:47:56 pm
-
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
-
just to show that it does work, when untransformed
-
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.
-
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 :(
-
Sorry, forgot the blender file.
-
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.
-
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
-
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 :)
-
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?
-
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?
-
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.
-
Hmm, I haven't tried the exporter mattn mentions. I've only tried the technique described here (http://www.katsbits.com/tutorials/idtech/exporting-models-as-bsp-maps.php). 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.
-
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.
-
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)
-
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.
-
but don`t forget about brushcount, it should not be big.
-
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?
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.
It is for good ol' Blender v2.49 (I am backward in this case). I merely touched up the ".map"-exporter (unfortunately cannot remember the author's name to give him credit here). Should I write a tutorial about all this? Maybe we can keep Blender-learning to a minimum.
Understood about UFORadiant. You are right, it can be minor touchup. In this case, where only 32x32x2 = 2048 brushes (=faces, since the rest is invisible) are involved, it is already a major issue (but shouldn't be for flat terrains).
But imagine having a size of 2048x2048x2 regular lattice for height fields ... would very much need to use the poly reducer in blender.
-
but don`t forget about brushcount, it should not be big.
You are right, of course, Kildor. Just mentioned the poly reducer in Blender: see this example:
Screenie 1: 32768 triangular faces in Blender
Screenie 2: 8172 faces
The same in UFOAI since the rest of the faces is invisible. Cannot be sure whether the bsp pass will break into even smaller faces though.
-
We can change the scale of the grid in Blender, I assume. Right now you're using 16x16 which is probably much smaller than it needs to be for our purposes.
Would be nice if you could share your version of the .map exporter in some format that those of us who don't compile can use (ie - is it just a plugin or something?). Also, a quick tutorial on creating the quad/trigrid in Blender would be useful.
-
I think it would be best if I prepared several input files in blender so that the hickups with learning it are not so steep.
Otherwise, people normally already get stuck with the view controls and how to delete the default cube, camera angles etc.
Will work on this probably tonight!
-
Ok:
short tut here:
- open the blender file (terr_128_1042.blend). it is composed of a 128x128x2 triangles grid. This is scaled as an object to 2040x2048 for terrain size in UFO/radiant
- click on "Assign plane" in the ANT landscape generator (right)
- Play with ANTs parameters
- the grid is automatically decimated, set decimation to your liking (and see problems later) to get as few tris as you want
- Use "File -> Export -> UFO Radiant Prism/Tetra" Exporter
- Settings need not be changed for terrain, simply put the terrain texture name in
- Export (is fast)
- UfoRadiant: open the map file (very slow, allow for 10 minutes, you mileage may vary from machine to machine and your decimation parameter in Blender)
- Insert player starts
- you are done
- compile
- play in UFO
Disclaimer:
- I am not a code god so don't look at it
- there "can" be problems with degenerate brushes during bsp compile step - no solution in Radiant due to complexity and sluggish handling: play with decimation parameters
-
The files:
- installing the script is copying into .blender/scripts next to all the other export_* scripts
PS: would be really useful to have larger scales for textures (> "1 1") see repetitiveness of textures
-
Cool! I will check it out tonight or Saturday.
-
A note on brushcount:
- see blender screenie: I used 1638 brushes (prisms)
- the bsp step makes them into 2234 it seems (see r_speeds viz)
Sizes:
- with solely "-extra" in ufo2map, these brushes get compiled into a 2.6 MB file
- with "-quant 2" we end up with 11 MB (and no visual difference, but this is due to the high sun angle = virtually no shadows)
-
very cool - i've added your script to our repository (src/tools/blender)
you could try ufo2map with e.g. -nocsg
-
it would be really cool if you could write a small howto in the mapping section of our wiki
-
There are some problem with height levels to think about. It is strange to walk your figures over continuous terrain and they suddenly disappear because they "switch" to the next level. Perfectly fine in architectural maps, but here?
See map as example. When you guys have time, maybe just playtest it, two aliens, two soldier starts. Idea is: there is an island with a crashed ufo. The guys come per boat and neutralize the aliens (ok, it is nowhere near pretty or anything, just for testing height transitions on smooth terrain)
Working on exporting brush height automatically ...
-
Hello,
another request for someone else to check this map, I am stuck:
I wrote an exporter that solely exports tetrahedra, works well in a sense that we can export all triangular meshes without hassle.
See screenshot: assertion fails with planenum >= 0. Map file is attached.
Thanks to anyone trying or having an idea.
-
Quick though: Make sure there are no walkable surfaces below 0 on the z axis (or maybe even right on 0).
Otherwise, I'm pretty busy until the weekend so wouldn't have much time to look, sorry.
-
Hi I tried again, this time wi th everythin well above 0.0 and still no luck ...
Would be great if you could give it a try, thanks
-
i will try to find the reason. a quick guess could be floating point issues - due to your rather complex geometry.
edit
it looks like there are too many planes and the unsigned short is overflowing
-
try to not make the terrain as hollow - but as full brushes from ground (level1) to surface - your brushes are too small in some cases, resulting in so-called microbrushes.
-
i've patched ufo2map a little bit to error out on compilation already.
removing some part of the map at least allowed me to compile it: http://mattn.ninex.info/screenshots/bigmap.jpg
-
now i found the bug - it was in the map loading, it isn't on your side. the fix is coming in a few minutes.
-
Nice
-
Wow ! :)
This looks impressive. Great to see your motivation, mameister !
I am excited to try out first maps built with this new technique !
-
Hi guys,
thanks for having a look into this, Mattn! I will provide the tetra-converter (with height level separation) soonish in this place,
Martin
-
@Mattn:
just to understand you correctly: did you have the time to fix the bug and how can I get it to run at my place?
Do I need a git checkout + compile myself or has someone prepared a "pre-2.4" binary already?
cheers, Martin
-
you have several options:
- download the night installer
- checkout the git repo and download the nightly binaries (no ide and so on is needed - but you will always have access to the latest fixes and data)
- checkout the git repo and compile on your own
you will find the nightly snapshots at http://ufoai.ninex.info/snapshots/
-
mameister, please check out latest master & join the team, so you can work on the latest version of things ;)
I think your input would be highly welcomed & I am sure your past work justifies enabling write access 4 u.
Here you can find detailed instructions on how to get up-to-date: http://ufoai.ninex.info/wiki/index.php/Getting_the_source
You can also join the IRC channel (#ufoai, irc://irc.freenode.org/ufoai) if you have questions or want to join discussions.
Here you can find the logs: http://colabti.org/irclogger/irclogger_logs/ufoai
-
Hi guys,
thanks - right now I am really busy with the harbour map and the tetrahedrons :)
So its ok if I am oinly a geometry/mapping guy at the moment, let me finish those open ends first.
Then I will proceed with a wiki page to show how terrain can be made with Blender (either prisms or tetras with explanation what the difference is) and maybe I could be convinced to hack it into UFORadiant :)
But that's some weeks off ...
cheers for the nightly build hints, will check this out
-
@Mattn
Downloaded "latest" but have problems since: ufo2map is started but without any console output it dissappears in the background. oes not return either. De-installed everything, downloaded the 800 Meg installer, still same phenomenon.
-
that isn't your fault. does ufomodel.exe opens a console for you?
-
No, it does not. ALso, when running ufo, it says (and aborts): "Item plasblade has invalid parameters"
I don't know what to do and will probably go back to 2.3 (.1?)
No idea what I should to to get this dev-version stable (Windows 7 , 64bits, Intel)
-
Here the latest git master version works on Windoze, so ???
You could try this 2.4dev version from December: http://ufoai.ninex.info/forum/index.php?topic=2830.msg45575#msg45575
, but still I would encourage you to checkout latest master version to more easily stay up-to-date & on the cutting (& sometimes bleeding ;)) edge of development in the future...
-
Guys, I am still stuck. I can compile with the 2.4 ufo2map or the 2.3 one but I cannot run in 2.3 and I can't run 2.4
When's 2.4 coming? :)
-
What are the problems you're having? Is it with running your map or the whole game? See here for reporting errors (http://ufoai.ninex.info/wiki/index.php/Bugs#Useful_bug_reports).
-
i will try to compile ufo2map for you manually - so you can use the latest version from the snapshots directory.
-
here we go: http://mattn.ninex.info/files/ufo2map.exe (thanks BTAxis)
-
Thank Mattn, tried it, same phenomenon
Well, my problem look like this:
- I have a working release 2.3 installation
- I can use ufo2map 2.3 for making levels
- I cannot use 2.3 ufo2map with my tetrahedrons, as in this thread, mattn explained to me that he did some work on ufo2map (also on ufo?)
- I cannot run 2.4 dev (Item plasblade has invalid parameters) from the nightly releases (my last full download is a while back, about three weeks)
- can run 2.4 ufo2map but do not have console output which bothers me
- the maps I compile with 2.3 ufo2map or 2.4 ufo2map crash UFO2.3 for the below examples
I want to keep a playable release version as well as a dev version for trying out the tetrahedron stuff. Not possible? Problems with Windows APPDATA-Dir?
Edit: I just compiled the complex2.map with your new ufo2map (in the zip) and get the same old planenum>= 0 assertion failed in 2.3 (I cant test UFO2.4)
It seems I need to use the new ufo2map and the 2.4UFO, this is not working on my side right now.
Thanks for having a look,
Martin
-
- can run 2.4 ufo2map but do not have console output which bothers me
I get this too, actually. It's not usually a problem though, just annoying that I can't get the usage help to print. Since I compiled this executable, it seems likely that my MinGW environment is somehow to blame. Maybe I should try getting rid of it and rebuilding it from scratch.
-
complex2 compiles fine here: http://mattn.ninex.info/files/complex2.bsp.gz
complex3 does not - but it does not error out, but loop endless - i will check that
-
here is the bug tracker item for the problem with complex3: click me (https://sourceforge.net/tracker/?func=detail&aid=3193940&group_id=157793&atid=805242)
-
btw. a big problem is still that the exporter does not create solid brushes, but hollows with surface brushes only. our pathfinding might not really like that.
-
http://mattn.ninex.info/files/complex2.jpg
the map has brushes > level 8 and there are some shadow artifacts (but that isn't your fault (resp the exporters fault) but an error in our renderer or mapcompiler)
-
Wow, sorry for the level hickup! I just wrote a function that checks for all vertices to be in a height interval.
Surface brushes I switched to because of the following features not being representable with the "extruded" polys heightmap type:
- terrain overhangs/cliffs faces
- caves
- stalactites
- natural bridges
Thank you all for looking into this
-
Just tried the level you compiled:
UFO2.3 simply quits, no error message, just complete crash when I try to load it