AEblocks - Modular Mapping

[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?

[AEon]

The shape in the gaps" is very angled, thus the 6 tris... the other thing I am trying to avoid is for the compiler having to create new t-junctions. My "filler" brush fits exactly. Oh, and I would also like to avoid additional overdraw.

If there is a way, as you suggest, I have no idea how.

If you want to give it a try, I can upload a cube wall .map, with filler brush to test.

[Shrinker]

So on the one hand you want to avoid having many little additional surfaces. On the other hand you don't want z-fighting. You could add darker patches behind the walls that have a bit of distance to them. So they are not triangulated too much and there's no z-fighting either.

[AEon]

Putting some form of dark screen behind the walls did occur to me... presently most walls in the box map directly "look into" the skybox. Any textured, unlit wall would massively reduce the see-through effect. This could actually be a very cheap and easy thing to do...

Will keep it in mind...

[AEon]

So did a bit more work these last two days on a new area of the map... the green sector.

• AEblocks - green north-west sector
  AEblocks - geometry experiments
  AEblocks - new flatter ramps

"Blocking out" the map... still a lot to do... especially refining a few things. Some ideas look OK in Radiant but with lighting less so... or compiled with lighting, some area "demand" more detail. The great thing about all this... changes can be done pretty quickly.

The nice thing about the block design is that ideas seem to just pop up for me... I look at an area, think it is too flat, so I add more height variation, and at least IMHO, it then looks more interesting. In a few areas, I'll differentiate the design more though... especially the rounded ramped corners in the map, look too "samey" ...

Another day, and the blue sector should be done too... then I can go in an stress test the layout a bit more. Alas bots will probably play the map really badly presently... no caulk hull no clipping... unusual for a map I built. Normally bot support is in there from the start. One slight downside to using blocks, alas.

[dONKEY]

Sorry if you've thought of this (i'm being lazy and didn't read the entire thread).
All the blocks are models?
Be careful you don't exceed the max model limit. some really odd shit starts to happen if you do. Quake will randomly start deleting models. I've exceeded limits a few times lately. When bots begin shooting rockets about you'll see what happens.
If you run into that you might find you have to combine individual models into single models.

[AEon]

dONKEY,
Thanks for confirming that... I did a test a while back where I only created an ASE model in Radiant for the main cube I use to quickly define boundaries. I must have replaced about 300 of the brush-based cubes with the model cube. And that already would no longer compile (32bit version of q3map2), did not try the 64bit version though. It failed to compile in the BSP stage outright. So it is indeed an issue to use many models, as you point out... alas. Admittedly, at the time I was already hitting a t-junc limit, so using more models might have been possible. But I gave up, since apparently I do need to do a caulking more or less on a per module basis in the map.

Side note: What I mean is, I would need to see what modules I need in what versions of caulking. E.g. a cube in the middle of a wall or floor would be a simple "panel". But when you put them on the top of walls, more faces need to be un-caulked... and that sort of thing would need to be done for all the other modules (ramps, stairs, glass cubes, etc.) as well. Not impossible, but compared to my brush-work modules that I can caulk as needed a pain to do...

Now I use brush-based and patch-based "blocks" that I func_group into one module each. I then went in and caulked all but the visible faces and that, at least up to now works really well... but I did use the latest q3map2 in the 64x\ folder of the GTKradiant 2.6.4 that is 64bit now.

It would be interesting to hear... did you ever find out what the limit of models was in Q3A?

Afterthought: Depending on how Reflex turns out, it might be possible to re-create the AEblocks map using models... if that game gets a form of model instancing. Which I think it will.

[AEon]

Finished the first version of the map layout... the pathing is now complete:

• AEblocks - the pretty much complete map layout
• AEblocks - "fat tubing" to block area under ramps
• AEblocks - central arena with a few temporary weapons and items, ramped the bridge
• AEblocks - blue area corridor

I will still probably add an AP to the map, maybe two... but this depends on how the map plays against bots. Alas, presently, the .aas (bot compile) fails. Since the map runs at 125 FPS solid on my almost 5 years old hardware, my priority now will be to make it compile for bots... by using player and bot clip... with all the curves in map this will end up being a lot of work. The caulk hull will need to wait.

[AEon]

Instead of clipping, playing around with Sock's Industrial textures... even though they look nice and add detail, they do detract from the original purist crete look. Hmmm... not so sure about this.

• AEblocks, steps - using the steps textures; might need to change the geometry to make the floor looks less "plastered"
• AEblocks, APs - arena with two new APs (animated)
• AEblocks, the other wall crete texture - stripe crete texture used for JPs, almost looks as if the brush geometry was real

[Theftbot]

http://www.mapcore.org/topic/1302-wip-i ... ntry384522

[AEon]

Theftbot,
oh, I am fully aware of what Castle has been doing... his latest modular mapping idea is a competitive CTF map you linked to. He releases YT videos on a regular basis about the things he "does":

• -=Castle Does=- on YT.

It is interesting to see how his projects and my map are starting to diverge more and more.

[AEon]

Shrinker rightly pointed out to me that, when considering cubes used on a floor, you would actually not want or need any gaps between the cube corners, since they are being used as tiles anyway. This means the cube corners, as seen from above, would "simply" need to be "un-clipped"... making a 5-faced floor tile again, using CSG Merge... and not requiring an overcomplicated and ugly plug brush I wanted to use. This also reduces the number of tris from "15.5" with plug to 10 "no gap" per panel.

Alas, only after building the complete map, and Shrinker's comment, did I note this... sigh.

Luckily I can retro-fix this by using a 4-part plug, only merging the needless corners to the main modules again. Talk about manual labour... sigh... Modular mapping is great if you have instances, if you do not, any mistake will be multiplied n-hundred-fold.

The problem is, again... my angled off cubes (on all edges) are still correct for a free-floating cube... but wrong for cubes in floors and walls. But on any two or more-side accessible surface... e.g. top of a wall... more manual tweaking will need to be done.

Well, it's all a learning process...

[Castle]

I like how this is coming along! You have a much more extensive list of modules than I do right now that's for sure too. Though I am only building them as the need arises. I really like how you did the stairs with ramps on either end.

[AEon]

... thanks.

It still surprises me that the steep ramps can actually be ran up in Q3A... in Reflex they would be pretty "huge" double-jump ramps.

One day I should install the UT4 SDK (it was available for download?) and take a really close look at your modules... are they actually edged off (bevelled)?... or are your cubes perfect cubes and just have a "dark" edge texture on them? Well, I am learning real edges are a pain...

Your new CTF map was an interesting application of quickly "blocking out" a map. With your 3 paths you might like to try to separate the two outside ones more from the main path... i.e. to make them slightly more secure... presently they seem to be pretty open from the central path. To be able to see the whole map from above, IMO, is another interesting approach to improve spectating. Though a "default" underground path falls flat, simply because it cannot be followed from above. This does make me wonder how many "significantly different" CTF maps can be build in this style, i.e. top down viewable.

I hope to build a second map with my blocks... very experimental and much more vertical. The good thing about fixing the blocks to work better is that the next time I can avoid all those issues...

[Shrinker]

The good thing about fixing the blocks to work better is that the next time I can avoid all those issues...

Pffft, we'll just find new annoying issues for you.

[AEon]

I fixed all the floors now... and the walls where holes are more notable will be fixed next (mostly). Though, due to the angled cuts on the other modules, namely any triangular ramps (my patch-based rounded corner ramps are pretty much fine)... fixing them will not be so simple. Might need to recreate them without holes.

Using CSG Merge to "glue on" previously cut off corners, at least brings down the number of angled faces, plus brings down the tris count slightly, aside of fixing the caulk holes. So there is some form of benefit at least.

Still figuring out what connections in geometry I want e.g. when floor cubes touch the wall cubes. Avoiding overdraw fails in a few cases... again need to rethink how to properly avoid it. In the latter case I am tossed between seeing caulk, and texturing with overdraw.

Alas, the quick building I had hoped the modules would allow, is brought down by my optimization attempts... fill holes, caulk unseen faces, do proper clipping and add a caulk hull... but I really would hate to not at least try to optimize the map enough to bring down the tris counts.

Still on the todo... make the bot file compile actually work again via massive clipping of pretty much everything. Though the lack of a caulk hull may also play into this... it might be that the huge box all the map is placed in presently, is seen as bot-playable space, actually I am sure it is... and that does not seem to be helping either.