AEblocks - Modular Mapping

[AEon]

Yeah... could do that for the default cube... just caulked everything as a test... that helped to get through the compile. Though an excessively invisible map may not be so great. A geometry replacement tool would be great, select all cubes, replace with their model

[AEon]

So, biting the bullet, used my properly bevelled cube from Blender, that was barely exported into .map format. Double-checked that the vertices were all on grid, then build a small caulk room, with player spawn, and put the cube into that room. Used my old ASE compile scripts to turn the "mini-map" into a textured ASE model, and added that to the main map. "spawnflags 4" set on the misc_model of the cube.

Next... need to delete about half the map to be able to compile it again, and then check how the cubes look on a floor and added to walls. I am hoping for the best, since in AEdm7 I had huge problems with models and lighting. Apparently it had to do with Sock's shaders (I was trying to use them in the wrong way apparently), these models have no shaders on them.

A question for the ASE experts:
When you build ASE models with GTKradiant, i.e. create those small caulk hull rooms for them, is it possible to externally manipulate the texture on the ASE model? I know that Sock used _remap for replacing of one texture on his ferns. Would it be possible to replace e.g. six different textures on the six sides of a cube?

I am aware this requires the creation of 6 shaders, one for each side, and in that shader I could use caulk. But this would then be for all ASE cube models, not just for the one individual cube.

I ask, because it would help to be able to more or less on the fly, plaster most sides of the ASE brush model with caulk... but beforehand I would not know which sides. E.g. a cube in the middle of the wall would only show one face, the other 5 faces would be caulk. (My cubes are more complicated, but that is for later.)

From a chat with Hitshot, he textures his ASE once and that is that, no on the fly texture changes. And Sock did it a replace of "all" textures" for his POM ferns.

Thanks.

[Hipshot]

ASEs just text, you can replace the textures using notepad outside any quake environment.

[Hipshot]

If you decide to change from brushes to models, you might have to bite that bullet even more. Cause, models wont have any non visible touching faces removed.

[AEon]

My brush modules are all detail to begin with... so there was no face culling. One reason for the compile error... a quick test could be to make everything structural again... though I suspect the compile will not like that either.

After testing a few ASE models, will manually caulk the detail brushwork modules... and see if that works... luckily my texturing is only pretty much crete and a bit of glass.

The text editor editing of the face textures would be trial and error on ASE models. Even worse than bad . That would mean creating ASE models for several states of culling... one face un-caulked, 2, 3, 4 ... etc... and that for every module... very unelegant and tedious.

I really had thought that other than the lousy frame rate in Q3A, I'd have no issues with any compile limits. Apparently I was wrong.

[AEon]

• quake3 2015-01-10 19-18-11-51.jpg

Here a Radiant shot (bottom left) showing where the ASE cube models are and the main image showing them compiled with spawnflags 4 set. I am happy to say, models seem to properly cast shadows and are indistinguishable from brush geometry. So if I really have to, ASE models are a fallback.

BTW, was there a way in GTKradiant 1.6.4 to turn off the orange frame around models? I usually used so few of them that turning them off was fine. Potentially now the map will be created from models... and the orange frame detracts.

• quake3 2015-01-10 19-25-27-83.jpg

Just in case someone is wondering how bad the unoptimized brushwork looks in wireframe. Yes, I am treading an evil path indeed.

[Eraser]

Even though the general geometry is not very detailed, there's a certain more-advanced-than-q3 look to it. Reminds me of Portal 2.

[AEon]

... good comparison... since they created the simple editor for Portal 2, that uses blocks all the way.

• radiant164 2015-01-10 22-12-50-10.jpg

The Tron-like feel in Radiant's view denotes the ASE cubes... about 300 I would say. So the amount of models is not really insane or anything...

Code: Select all

--- MakeEntityMetaTriangles ---
0...1...2...3...4...5...6...7...8...9... (0)
    17642 total meta surfaces
    17108 stripped surfaces
       54 fanned surfaces
        0 patch meta surfaces
   142487 meta verts
    83257 meta triangles
--- TidyEntitySurfaces ---
    17642 empty or malformed surfaces deleted
--- SmoothMetaTriangles ---
No smoothing angles specified, aborting
--- MergeMetaTriangles ---
0...1...2...3...************ ERROR ************
safe_malloc failed on allocation of 8 bytes

And just when I "fixed" the issue of T-junctions, and having added a few hundred ASE model cubes instead, I run in this error in the BSP compile... my bevelled cube ASE model, has textures on all sides, but is solid (at least)... MergeMetaTriangles started to really take long. Is q3map2 starting to merge faces of my cubes models, trying to reduce the number of tris? Since the cubes are touching each other on at least two sides usually, a lot of merging seems to be needed.

So much for using an ASE model to "block build the layout", to then add brush-based modules for details. I suspect I might need to create more ASE blocks that are mostly caulked, and use them in the proper places... i.e. like manually caulking the brush based cubes.

Oh, boy.

I wish q3map2 would tell the mapper more specifically what is going wrong, like "hey, stupid you have too many touching ASE models", or "cut the number of ASE models, you have #, but the limit is #...". An insulting compiler... that might be hilarious... maybe not.

[obsidian]

What compile switches are you using? You aren't using the clipmodels spawnflag, are you?

[AEon]

Code: Select all

call cd "D:\Games\Quake3\baseq3\maps"
call "D:\Games\!q3map2\q3map2.exe" -v -meta "D:\Games\Quake3\baseq3\maps\%1.map"
call "D:\Games\!q3map2\q3map2.exe" -vis -v -saveprt "D:\Games\Quake3\baseq3\maps\%1.map"
call "D:\Games\!q3map2\q3map2.exe" -light -v -fast -patchshadows -dark -samples 3 -bounce 8 "D:\Games\Quake3\baseq3\maps\%1.map"
call cd "D:\Games\Quake3\Radiant-bat"

Not using any fancy flags on the ASE models. Just "spawnflags 4" for the lightmap. I sent Hipshot the map, he wanted to tinker with it a bit. Presently giving up on "mass-usage" of ASE models. Returned to my original brush-based module approach, but this time caulking every unseen face. To significantly bring down the number of tris and angled edges.

Fixed:
My present compile, with the latter approach, using 64bit q3map2, seems to be stuck at

Code: Select all

--- PassagePortalFlow (3038) ---
0...1...2...3...4...5...6...7...8...9...

I removed all models, and started manually caulking all brushes as mentioned (though that is only 20% done presently). All geometry is detail. But no matter for now. Will caulk the rest of the map, and then it should become clear if problems are still there.

I had some very narrow geometry "sticks" to fill in my floor gaps, these were structural (by accident)... seems the compile did not like them one bit. Made them detail... now compiles through. Sorry about that.

So seems the combination of 64bit compiler and massive caulking are getting the compile working again. A relief... and since the rest will also be properly caulked... I should finally have some leeway to make the map larger.

[Castle]

What about disabling T junction fixing in the compile process?

Hmm it sucks to see you hitting a wall with this in Quake 3. Something I have noticed about building this way is it tends to give the environment weight if that makes sense. Almost more realistic in some ways. Its kind of strange.

When I look at your level I see the same thing.

[AEon]

Castle,
luckily I seem to be getting the upper hand again. Compiling works, detail can again increase... the holes in the walls we will henceforth define as a feature ... saves tris.

But I still need to manually caulk all the brushes / modules already placed. The good thing about all this, it gave me a few ideas on how to improve the map. While pretty much rebuilding it... since properly texturing a block once to then clone it, is faster than texturing all the other blocks again and again. Strange as that may sound.

In one video you mention having to possibly raise your bridge... had to do so too today. Well I lowered the floor. Hitting your head on the bridge (even if you usually miss) just makes the map feel needlessly cramped.

I am not quite sure about the "environment weight"... I would have said that there seems to be a certain comfort in seeing geometry parcelled into understandable portions... it always makes me smile when I understand that this, this and that brush made a certain shape possible, and that shape actually looked more interesting than any of its parts alone. Maybe its a nostalgic set back to Lego building days. One thing that also seems to appeal is the look... it is simple, yet elegant per se... and for now unusual. Mostly because no one in his right mind, over all those years, would "waste" polygons on a "real edge". But a "new" appreciation for shapes returns with this building method... most certainly.

Yesterday I actually got more of the map built, and I really enjoy the process of "block building". I started to look at certain designs that came up and thought... need to move that area by one block, to make the shapes better align... and then you actually do it, since it is possible without throwing away huge amounts of work. This freedom... will need more exploiting... but is nice to have.

[Theftbot]

Do you have a pack w that sky(sky shaders)

[AEon]

Not really the skybox is from Hitshot... Miramar. But I can post my current version of the skybox shader (perfectly aligned to the location of the sun), that I only edited yesterday after obsidian's post in Pat's map thread... if anyone can still follow that . I have not tested the latest changes to the skybox shader yet.

[AEon]

So, finally caulked all the brushes making up the modules... quite aggressively, since the "holes" between the cubes are now see-through. Wonder if I can get away with such a design. Since, seeing the skybox directly though "gaps" in the geometry has been avoided thus far. Plugging the holes is a pretty daunting task, but I build the plug already and it costs 6 tris per hole in the walls and floor. Will be interesting to see what a caulk hull will have to say about detail brush holes in walls.

Outside the map, before caulking I could see everything, that was 43k tris... my caulking brought that down to 24k tris for the complete map. A caulk hull should get it down to under 20k easily (I hope). The map compiles and runs pretty well... so seems I can expand the design further. Whee

Anyway...

• AEblock - fully caulked

the wall cubes now have become more like panels. I find it interesting to be able to actually see into the map from the outside. Strange how that actually looks cooler in a few areas than actually being *in* the map.

• AEblock - fully caulked (2)

I am still defining a style... presently the rounded arcs above the map walls do not really fit the angled parts I am using elsewhere. The great thing about all this, they can be swapped out quickly enough. The curved corridor "corners" on the other hand work relatively well, IMO.

And, yes that huge crete wall in the background is a texturing bug... accidentally replaced the skybox with crete...

Corridors now all have filler lights to brighten them up... since the skybox does not add enough light into them. Though shadows are still well enough defined.

Not sure why, but somehow the map reminds me of Logan's Run... TV series... one of the sanctuaries Logan had hoped to find. Grit decals and plants are definitely something I will want to add later. Who knows I may actually be able to build some plants using Blender... if I ever understand how texturing in Blender works...

[AEon]

Had to post this shot too... using the yellow crete texture as a base, I created some orange, green, blue and red ones from Sock's Industrial Set...

• AEblock - Colour Painting

Somehow this exudes happiness

I probably will need to create new lights too, based on Socks work.

[Castle]

Man that looks really cool!

I like the way the spaces have a very comfortable feeling to them in this style of design too.

[AEon]

Thanks ... whereas you actually test your map in the the real world, I tend to run about the map trying to see where paths might go... what works, what does not... at the same time trying to get some height variation into the map.

As you commented in your last UT4 video... also noted the steep ramps, are too steep. I am actually favouring steps presently, even though they take up many tris.

• AEblocks - tubing up close (might require grouping to properly light the tubes consistently)

• AEblocks - ramps and tubing modules

I also had the idea of adding tubes... but you were a lot faster implementing them than I was. The above screenshot shows what I built today... I especially have high hopes for the tubing along the curved 90° walls, and really hope the ramped curved path with tubing will work. Using Sock's textures to texture the tubing.

Tubing as wall decoration, will probably give the map a heavy industrial look... so I am not quite sure about it... being modules though, I could relatively quickly remove them again if it goes the wrong way.

I also noted that the coloured "blocks" on the walls, let me differentiate areas of the map, in another area the walls have blueish tiles. And it ads a slightly modern museum look...

[AEon]

I started to add the tubing... and here one can see an interesting design dilemma... at least IMHO... keep the detail low and stick with a friendly look or go for more detail, so in fashion nowadays, adding tubing all over the place.

Castle,
BTW... I think you pretty much already ran into the same problem. Your metal-work brush-modules add a nice contrast to crete in the map... and they add detail too... but the initially nice "purer" crete looks is starting to get compromised. Maybe its just me... I like things as simple and as elegant as possible.

Tubing, at least in the slanted way I use it, creates a *huge* amount of tris. Not such a good thing.

• AEblocks - tubing... Quake castle

This shot really suggests everything is pretty much fine... the shot reminds me of a very modern Quake base interpretation... almost like an industrial castle...

• AEblocks - tubing... in perspective

But from this perspective there is way too much tubing going on... around the doorway frame it might be OK... but above that it actually blocks the open view the map used to have. Will be keeping the tubing in the rounded sloping paths, but will remove it again where it is blocking the view.

I think I will have to be very careful not to make the map too dark - in lighting and also in theme (whatever theme that may be).

[AEon]

Early morning mapping seems to yield results presently... as mentioned, removed the "trivial" tube solution, blocking the view... making more out of the windows...

• AEblocks - view restored

This different solution let me also show off a few other tube modules I had prepared... and IMO looks better too:

• AEblocks - new tubing outside of the windows

I will exploit this idea more now.... sky view where possible, and the same for views into the skybox. And more glass too.

[AEon]

Mostly clean-up and slight redesigns...

• AEblocks - blue sector

This different sector, features large curved windows... even though the sun of the skybox is very heigh in the sky, it does not let enough light into the corridors... so adding more glass. Filler lights are already in the corridor as well.

[Shrinker]

Looking quite nice, but the little gaps between the blocks should go away.

[Eraser]

Looking quite nice, but the little gaps between the blocks should go away.

Yeah was just thinking about posting this as well.
What are your intentions Aeon? I don't like the look of the gaps, but maybe you like it.

[AEon]

It is not so much liking the gaps, as a consequence of the basic angled off edges of the cubes. I was wondering if I could get away with it... apparently not. I already have the proper "filler" geometry built... though in a few areas it might get problematic... anyway 6 tris per "filler" extra... and there is a lot of filling to be done.

The holes are pretty much optimisations, in this case visual, along with a caulk hull, player and bot clip that all still need to be done once the layout settles down. Another optimization will be to replace the cubes with much larger wall panels... I use the cubes are basic spacers presently... so cutting down on tris still has some potential.

I actually wanted to create 2 or 3 arenas... but not knowing the limits of what can still be compiled, I am going for one arena with corridors around it. So the map will be pretty compact.

So in short, filling the gaps is on the todo... though I will hold it off until at least having one playable version of the map out. This way anyone interested can test this in real time and see how annoying / different it ends up being while playing.

[Eraser]

Can't you just create one big indented brush per wall to cover up all the holes in that particular wall?