Blender mapping

[golden_boy]

I snipped this from another thread.

re: mapping in Blender
re: Blender vs Radiant

You can use cubes to block out in Blender. Turn on grid snapping and get a feel for it - it snaps to the smallest grid that's currently visible in the front/side/top views. Then just extrude your walls from cubes. The downside is that you'll get a lot of useless triangles in your game-ready model, unless you manually delete all the faces that don't actually make up walls. That would be super tedious. So that's why I wouldn't use this method.





Something like this could probably be exported to .map though, as long as all the blocks are legal brush shapes (convex). But then you'd have to make sure that is the case... note that with the extrude method, your blocks won't actually have 6 sides. The side you extrude the next block out of will be left open... This method is also very tedious when it comes to making floors and ceilings. Radiant actually does a better job at this since selecting individual blocks (brushes) will be a lot easier, and you'll do a lot of that.

There's a better one:

You can try just blocking out your level with vertices and edges - lines, basically. Then you can extrude the edges upward to get faces... and that gives you a 3D environment. This would in practice look much like DOOM mapping, only the "linedefs" get extruded to form 3D planes.





Much simpler, less cruft! Easy to texture and export to .obj or .ase for FTE/Darkplaces, or to .fbx or whatever for Unity etc.

You can get a level like this to collide properly in FTE/Darkplaces, by using mesh collision. In FTE you'd just create a copy of the mesh and texture it with a meshcollide shader. In Unity it's even easier to get meshes to collide.

[golden_boy]

(Adam wrote) @GB, if you're making Quake maps using Blender, do you export as a .map and compile with a Quake map editor or is there a way to (compile &) output .bsp files with a Blender plugin?

I like the idea of using Blender to build maps but does it cause any problems when compiling them to .bsp? I'm refering to Quake and it's love of concave brushes...
If I'm talking rubbish, I apologie, it's cause I'm tired...

I export .ase or .obj from Blender, import the geometry to Radiant and place the entities there. Then I save the .map from Radiant and compile with q3map2. It includes all the meshes in the .bsp.

There is a Blender .map exporter but like I said, you'd be limited to build your entire level from 6-sided boxes then. You could vary the boxes to become wedges etc but only as long as they're 6 sided and convex. And this process would be tedious in Blender for practical reasons.

The .obj/.ase export method is better.

[Adam]

I guess that there is a demand from Vis that the levels you make are constructed from convex brushes even though it only constructs (or compiles) the level from the inner level surface?

To put it another way, When you build a cube\box level from six joined brushes, each being six sided also, once it goes through Vis, the engine only renders the internal six sided box, the contained portal?
=/
That didn't come out any better!

If that is the case, it is a shame, as building with blocks is less efficient compared to just the planes that get rendered.


So just for clarification, If you export a Quake level (that is just the internal planes) from Blender as an .obj file ,
then Radiant will extrude out those planes into brushes so that you can output a .map file that can then be compiled using any Quake level editor?

Or, noticing that you compile with q3map2 (which I guess is a Quake3 map compiler), maybe it doesn't require levels made from brushes (just internal planes)?
I think Q3 is still a portal based engine tho' right?

I will always love Quake editing but using just Blender & Unity to make games has a certain allure to it.

[golden_boy]

Radiant doesn't extrude the model faces to make cubes... nothing like that.

The Quake 3 bsp format can use meshes as part of the level. They get compiled into the bsp file. It doesn't need to be all brushes anymore. And Darkplaces / FTE can use Quake 3 format .bsps in Quake.

You can't do the same with the Quake 1 bsp format. You can have mapmodels in Q1bsp but they can't be lightmapped (they are lit by the lightgrid.) So you can't have an entire level made from mesh in Q1bsp.

Regarding vis and leafs/portals, yes, a mesh based level doesn't create any portals (unlike BSP.) You will have to either box the level, using one giant vis leaf, or put in vis blocking geometry made from caulk brushes. Today's hardware is fast enough to no longer need vis, though, especially not in something as simple as Quake levels. So yeah, box the level with caulk brushes in Radiant and call it done.

[Adam]

Ok, thanks for the clarification.

It would appear that although it could be said that we are making Quake mods, because of the feature advancement of DP, FTE and similar,
we are actually making Quake3 mods (as far as map & model formats) but with Quake's code base.

Is there a reason not to go full Quake 3 based?

Could Darkplaces and FTE support going full Q3A with a project?
Why am I asking this in a Blender mapping thread?
Cos I am a nightmare for derailing threads, that's why!

[golden_boy]

Ok, thanks for the clarification.

It would appear that although it could be said that we are making Quake mods, because of the feature advancement of DP, FTE and similar,
we are actually making Quake3 mods (as far as map & model formats) but with Quake's code base.

No. The monsters, weapons etc. are Quake 1. So is the progs.dat. Just the BSP is Quake 3 format. You can well use Quake 1 textures in a Q3 format map, too.

The model formats (.obj/.ase) are compiled into the BSP. The engine never has to load them. It just loads the BSP and the textures.

Is there a reason not to go full Quake 3 based?

Sure. You'd have to rewrite the gamecode in another language for that. No more progs.dat.

Could Darkplaces and FTE support going full Q3A with a project?

Only FTE. DP doesn't support multi stage shaders and as far as I know, DP never claimed to be able to run Quake 3. And I wouldn't trust FTE to run Quake 3 without bugs, either.

[Adam]

Apologies, I was generalising too much, I wasn't meaning to say all of us or targeting any specific mod.

I was thinking more on a surface level.
I realise all the code would still be based on Quake but if you did a total conversion and built all the assets (including coding custom entities etc) from scratch using, for example the md3 format to build your weapons, enemies & items and the Q3 map format.
You could get something that looked at least pretty close to a Quake 3 level project in DP/FTE. Maybe?

I know that I'm digging myself out of a self made hole here but I think I have learned something,
The Quake code base is the deciding factor, not the things you bolt onto it.
I'm no qc coder but I'm thinking that it is highly regarded, well documented and user friendly. Otherwise, we would be talking about this on a Q3A forum.

[golden_boy]

I think if we're talking total conversion, you get this weird hybrid of Q3bsp format, QuakeC gamecode, Q1 engine with extensions, and possibly md3 or iqm models. One would probably use iqm because it's a skeletal format whereas md3 is not.

Both engines support custom textures, normal and specular maps, and Q3A shaders, and the lightmaps will of course be created by the Q3 map compiler, and you'll be able to use curves (patch meshes), so your level would perhaps look somewhat like older Source levels. Portal, Portal 2 type look.

Q3 doesn't support specular maps etc. So if you go without those and use md3 format for your models, you'd get something that looks similar to Q3 but neither engine, as far as I'm aware, is 100% compatible with Quake 3. So you'd use the same model/bsp/texture formats but a) Darkplaces doesn't support 100% of the Q3A shader language, and b) I believe FTE isn't 100% Q3 compatible or if it is, I'm pretty sure there are bugs.

So you could get maybe 85% Quake 3 in your Quake. Looks wise anyway.

[Adam]

That's all really interesting to know.

Regarding the md3 format : I use a Blender plugin to export my models as .md3, I do it because it doesn't funk with your vertices as much as .mdl does.
Anyway, back on point, I animate my creations using armatures and bones, doesn't that make it a skeletal format? Or is it that Blender (.blend) is skeletal and the plugin/export process takes that part out?

Have you dabbled in Q2 & Q3 code? How does it differ?
I thought idtech code was built by just adding onto the last version but I guess not?

Sometimes I find it hard to convey what I mean through words. Telepathy would be so handy, nicht wahr?

[golden_boy]

Yeahh, telepathy would be handy.

The difference about skeletal formats is that the bones etc get saved inside the model. So they can be accessed from the engine / the gamecode to do stuff like ragdolls and animation blending. IQM does this, MD3 does not.

I have dabbled in Q2 code. The difference is that it's written in C. It's basically a pretty direct translation of QuakeC to C. So there is no progs.dat but instead it's a .dll.

I have no experience with writing Q3 gamecode. I only know that it's more similar to QC in that it runs on a VM.

[Spike]

Adam:
FTEQW - Screenshots - q3 support
No, its not bug-free, it doesn't get enough attention for that. It should run vanilla Q3 well enough though, assuming Q1 tweaks didn't break it lately - like I said, it doesn't get enough attention for bitrot to be caught reliably. FTE lacks extensions specifically targetting Q3, its not that I'm against any, its just that its pointless unless someone is going to depend upon them.
Q3 gamecode is typically written in C, and typically compiled as a dll at least for development. Its typically recompiled into a .qvm before release, as this allows sandboxing and thus automatic downloading. Q3 gamecode differs from Q2 gamecode in that Q3 has client-side gamecode that can be updated+customized+depended upon. This means that server-side entities all deal with trajectories and the cgame figures everything out. In contrast, Q2 sets only current origins, and has to set up various hud descriptions in some fixed and limited format for the unyielding engine to interpolate or interpret. Q2 is simpler but much more limited.
Any advantage of 'csqc' applies to Q3 just as much as it does to a quake engine with csqc. The difference being that Q3 has a more extensive base to work off that already does pretty much everything that it useful to do clientside, while csqc is from scratch.

What you have to remember is that Quake3 is a really old game now. Really the only reason its still relevant is because full realtime lighting is really expensive.
Its bsp format is almost a perversion of the original expectations, with trisoup being the only part that is relevant, with the lingering brushes being used purely for blocking pvs.
Its md3 format is used because tool support is widespread still.
Its shader format is outdated, limited, and awkward, which is why engines that do claim support are so often so limited, using extensions to it more so than than actual support. Typically they're only used because q3map2 expects them.
On the plus side, the fact that all these different tools exist to do all these different things means that its still very relevent.
And really, who am I to judge relevance when I'm working on what is basically a 20 year old game.

Thinking about it, it might be interesting to drop the pvs and use area portals in a doom3-like way, at least for batching.

[golden_boy]

In the final weeks of my q3bsp/FTE experiments, before I dropped the Quake engine, that's about what I did - I disabled the automatic generation of vis portals and started to manually insert (hint) portals where they made sense. Areaportals and antiportals were part of that strategy.

Not quite what Doom 3 does (manually inserted portals in doorways etc) but something similar with much less portals than vanilla Quake/Quake 3. I found this not only sped up compile times, but actually increased the frame rate in game. Probably because it allowed the engine to do more efficient batching.

These days when I look at the minimum system requirements of Unreal 4, I doubt that vis is even needed anymore. A simple distance-based culling or fog of war type thing might be enough.