Q3 .map -> Reflex .map converter

[AEon 256]

It does slightly bring tears to my eyes considering the work I put into AEdm7r, manually recreating brush by brush from the original map... now I can use your tool and create it in a jiffy... well I did change the map and made it more abstract. Still just goes to show the power of your converter.

[Devil 154]

What mirroring issue?  Perhaps I didn't notice because I'm working with a symmetrical CTF map?  Still want to try the new version regardless just to see those brush replacements do their thing.  This is all very exciting stuff.  I see your point about trying to make it too easy.  At someone point I have a feeling that practically every Q3 map is going to be remade.  Just seems like that is the way it's going to go.  We haven't even really touched upon CTF maps either.  In hindsight it's amazing that people have already completely remade some maps brush by brush.

[chronokun 57]

I made it generate brushes from patches now
https://www.dropbox.com/s/kcgzdm8tqao9sb1/Q3ToReflex_r9.zip?dl=0

[AEon 256]

I'll give it a shot later on. Should be pretty nifty. BTW...

 

How do you decide with  a "perfect" cylinder by how many "sides" it should be approximated? I assume it is s fixed number like 16? (8 would be a bit low).

[AEon 256]

Using r9...

 

Tested two of my older maps that use quite a few patches. The first map AEtime (2 MB) turned into 27 MB of Reflex file. Loading it causes a error on the console right away. So would not load. The other map AEarcs (also 2 MB) ended up as 37 MB .map file and apparently aborted very early on loading, almost all brushes were missing when entering the map.

 

The maps load without an issue in GTKradiant... so the format seems not to have changed. Might be a good idea for me to create a small test map that uses only a few patches, to see how that goes. Such very large .map files may be an issue with Reflex though.

 

Back then I did not really push what could be done with patches... but I did use quite a few. Strange.

[AEon 256]

Did a quick test... 90° curved wall using one patch that I capped on top. Turned into a curved wall with 5 sides so a circle would be 20 sides. These patch approximations are "paper thin" for a better word. But seem to work in this test case case.

[Bonuspunkt 167]

@AEon do you have any `#` char in the reflex map file?

[AEon 256]

Well spotted, in AEtime, the map conversion that directly showed an error and exited there are 93 such "#", e.g.

brush
    vertices
        272.000012 432.000019 0.000000
        270.848021 432.512034 0.000000
        269.952028 432.128045 0.000000
        272.000019 432.000031 0.000000
        -1.#IND00 -1.#IND00 -1.#IND00
    faces
        0.000000 0.000000 1.000000 1.000000 0.000000 3 2 1 0 aetime/e8cretefloor01
        0.000000 0.000000 0.000000 0.000000 0.000000 1 4 0 internal/editor/textures/editor_nolight
        0.000000 0.000000 0.000000 0.000000 0.000000 2 4 1 internal/editor/textures/editor_nolight
        0.000000 0.000000 0.000000 0.000000 0.000000 3 4 2 internal/editor/textures/editor_nolight
        0.000000 0.000000 0.000000 0.000000 0.000000 0 4 3 internal/editor/textures/editor_nolight

if that helps.

 

[chronokun 57]

Well spotted, in AEtime, the map conversion that directly showed an error and exited there are 93 such "#", e.g.

brush
    vertices
        272.000012 432.000019 0.000000
        270.848021 432.512034 0.000000
        269.952028 432.128045 0.000000
        272.000019 432.000031 0.000000
        -1.#IND00 -1.#IND00 -1.#IND00
    faces
        0.000000 0.000000 1.000000 1.000000 0.000000 3 2 1 0 aetime/e8cretefloor01
        0.000000 0.000000 0.000000 0.000000 0.000000 1 4 0 internal/editor/textures/editor_nolight
        0.000000 0.000000 0.000000 0.000000 0.000000 2 4 1 internal/editor/textures/editor_nolight
        0.000000 0.000000 0.000000 0.000000 0.000000 3 4 2 internal/editor/textures/editor_nolight
        0.000000 0.000000 0.000000 0.000000 0.000000 0 4 3 internal/editor/textures/editor_nolight

if that helps.

Yep that helps, looks like it is failing to calculate a valid normal for those specific patch segments when attempting to add the extra point that gives them the volume they need to be brushes, I'll update the normal calculation to use a more accurate method and add a check to make sure there isn't any still slipping through.

If you can send me an example map with at least one such patch to test with that would be great so I can check that my changes work after making them?

[AEon 256]

I will try to narrow down the part of the map that is causing the issue and zip the map part.

[newborn 1,997]

Just a heads up - if 30MB maps don't work, we're unlikely to be fixing them.

[chronokun 57]

Just a heads up - if 30MB maps don't work, we're unlikely to be fixing them.

Fair enough, I personally never had any expectation that your engine should accept pathologically complex brushwork That said it is holding up pretty well atm but the map load times with excessive amounts of brushes will I think prevent anyone from wanting to play those maps anyway haha

Looking forward to some native support for curves though and a way to import meshes, making this stuff out of brushes is a pretty ugly hack.

On that note, here's r10, it has better normal calculations so hopefully wont generate broken patch brushes

https://www.dropbox.com/s/k8ngvuib15x52t7/Q3ToReflex_r10.zip?dl=0

[AEon 256]

Looking forward to some native support for curves though and a way to import meshes, making this stuff out of brushes is a pretty ugly hack.

 

Is that actually planned for Relex to get Patches?

 

Never read about that so far. If so would love it... John Carmack never liked patches, I felt it was what made Q3A maps special... because a spline just looks so much better than some crummy brush-based approximation (not dissing your efforts chronokun, I mean in general). Though patches did have issues, e.g. with t-junctions requiring explicit caulking and cutting up of brushwork to avoid sparklies.

 

Will test r10... and see if this solves the load error.

[Bonuspunkt 167]

Just a heads up - if 30MB maps don't work, we're unlikely to be fixing them.

27,3MB works so good job @ engine

 

Will test r10... and see if this solves the load error.

yes it does

[AEon 256]

- "common/clusterportal" };
+ "common/clusterportal",
+ "common/trigger" };

Noted you are also deleting trigger brushes... often quite some effort was put into them to not get stuck when using them. So, IMO, it would be better to keep trigger brushes. Though at this point in time you need to recreate them in Reflex, but at least one can look up the size.

 

You might like to add "skip" to the above list... some older maps used to use that instead of the "hintskip" shader:

+ "common/skip",

thanks.

 

Alas due to the ReflexFiles Wiki, my patch testing ground to a halt.

[Devil 154]

Tried out r10 and the results are spectacular.  Every single curve is in there now but it uses 10 times the amount of brushes to do curves.  This has increased the map file size from 1.3MB to 14MB.  I'm getting about 15 FPS and map is unplayable due to the brush count.  There's no way I can use this as a base to do Reflex optimizations and refinements.  There's simply too many brushes now.  I think r7 made a very simple version with a manageable amount of brushes.  Maybe a few thousand but r10 increased that amount 10 times.  Yes it converts it beautifully and perfectly now but the geometry is so complex that the engine can't handle it.  Now it's at the point where I don't even want to do a conversion because it would consume weeks if not months of my time to scale the brush count down to a manageable level for performance.  I think r10 works a little too well for the current engine to handle.  I'll take some new screenshots for you to see.  It's an absolutely stellar replica now and looks amazing but performance is in the dumpster.

[chronokun 57]

Tried out r10 and the results are spectacular.  Every single curve is in there now but it uses 10 times the amount of brushes to do curves.  This has increased the map file size from 1.3MB to 14MB.  I'm getting about 15 FPS and map is unplayable due to the brush count.  There's no way I can use this as a base to do Reflex optimizations and refinements.  There's simply too many brushes now.  I think r7 made a very simple version with a manageable amount of brushes.  Maybe a few thousand but r10 increased that amount 10 times.  Yes it converts it beautifully and perfectly now but the geometry is so complex that the engine can't handle it.  Now it's at the point where I don't even want to do a conversion because it would consume weeks if not months of my time to scale the brush count down to a manageable level for performance.  I think r10 works a little too well for the current engine to handle.  I'll take some new screenshots for you to see.  It's an absolutely stellar replica now and looks amazing but performance is in the dumpster.

I can reduce the curve resolution at the cost of them not looking as good but even so it will probably be necessary to just clean your maps up as much as possible before converting them as they'll still result in far from optimal geometry and there will still be all those brushes from decals and such needing to be cleaned by hand anyway so maybe I should just include an option to include them or not and set the resolution in the next version, hmmm.

[AEon 256]

Maybe allow command line parameters to control the converter? E.g. by default turn off the patch conversion, and via arguments:

Q3ToReflex -patch 5 <q3map>.map <reflex map>.map

control the number of brushes per patch. In the above case, and I think that was the last default I checked, 5 brushes per patch. Not sure, but could a "-patch 1" actually do a linear approximation of a patch, i.e. in a 90° patch just "angle it off"? I.e. joining only the patch "ends" with the brush. Then again the patch caps, seem to be really difficult to do too.

 

Anyway... amazing that it is possible at all.

[Devil 154]

Here's the difference between r7 and r10.  Jump pad area was square in r7 and in r10 it's a really nice curve.

 

 

All the clip brushes show up correctly this time too.  This is about as good of a conversion anyone could possibly ask for.

 

[AEon 256]

Oh... clipping gets converted... that is neat. Alas the way Reflex handles clipping, every brush will need to be handled. But this is not me complaining... it means one could fix the Clipping the way Reflex needs it in GTKradiant... and that alone should really help.

[Mazu 83]

Thank you for this tool chronokun!

 

Tried this out with one of my earlier cpm maps and it helped a lot on recreation process. Replacing textures on text editor and adding a fitting color theme in game was really fast way to make this map in Reflex. I'll wait for improvements before converting more. Keep it up!

[doublethink 9]

I can reduce the curve resolution at the cost of them not looking as good but even so it will probably be necessary to just clean your maps up as much as possible before converting them as they'll still result in far from optimal geometry and there will still be all those brushes from decals and such needing to be cleaned by hand anyway so maybe I should just include an option to include them or not and set the resolution in the next version, hmmm.

 

Since its command line, could you add a few arguments people could use to adjust things?

 

Such as:

 

-curve_draw    0/1   (hard on/off for curved surfaces)

-curve_resolution  1-5

-brush_ignore   0 = off  any number being the min thickness of a brush to not convert, for example, 2 = 2units or thinner, ignored

 

Great job anyways!  

[AEon 256]

Since Q3ToReflex keeps most of the file names in the converted map as they originally are, it occurred to me that using Reflex's texture set (and their very same paths) in GTKradiant, would let me fix textures *before* converting them to Reflex. Radiant has a full set of texture alignment tools so that should help.

 

In this post:

 

AEdm7r on Quake3World

 

you can see how a few textures have already been replaced via in-editor texture search and replace. I still need to work on the texture size, i.e. in Radiant vs. how it looks in Reflex though.

 

Just wanted to show what is possible.

[AEon 256]

chronokun,

I hope you are still motivated and have the time to look into texture alignment in your code. I have ported my darkcaulk texture to GTKradiant, and placed the texture in GTKradiant (texture lock off, no offset, no rotation) and then took screenshots how the textured are orientated by default... then used r10 and converted it to Reflex, and took those screenshots again.

 

(There is a texture scaling issue between GTKradiant and Reflex, by a factor of 8, but I will fix this by scaling down the textures for Radiant. Lets ignore that for now.)

 

Will upload the screenshots in a moment... hopefully you can sort out the texture orientation issues. The "fit" used in GTKradiant seems to work.

 

Q3ToReflex .map converter - Texture Orientation

 

Put up a thread with screenshots... hopefully they are of some use.

 

Thanks for all the hard work.

[AEon 256]

Did a bit more testing... placing darkcaulk texture on a brush in Reflex, and comparing it with what the conversion yields, there is a factor of two between them. So from Radiant to Reflex the texture dimension get halved. Or put differently after conversion 8 darkcaulk fit into 128u, Reflex itself fits 4 darkcaulk textures into 128u by default.

 

This could be due to the way Radiant works with textures, by default any texture you add to a Q3A map is halved (scale x,y: 0..5) in size before it gets displayed in Radiant. So that you get 2 pixel per 1u.

 

Interestingly the ratio used in Reflex is different... the 256px darkcaulk texture fits 128u, four times, so 8px per 1u.