Welcome to personalidol Discussions!

[mcharytoniuk]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[victorbstan]

I have a question about the .map parser, does it generate optimized geometry, the way that parsing the .map files into .bsp files, using .vis, etc. would cull non visible faces, and faces that can never be seen by the player?

[mcharytoniuk]

Hello. This parser converts .map files directly into THREE.js geometries. I am using it in an isometric projection in RPG / strategy game which I'm still working on, so I had different assumptions than 3D FPS games.

1. It does not dynamically cull faces that are not visible to the player. Instead it's used in a game with a mostly fixed camera angle, so it has option to not include faces that would not be visible when using that specific camera angle (which conserves memory, so it's easier to make it work on mobile devices - they often have less than 64 MB of VRAM).
2. It supports custom attribute that you can add to a block in Trenchbroom (for example to a building roof). Then when player character is between a camera and that specific block, you can then make that block semi-transparent (for example a building roof disappears when player character comes inside the room, so you can see what's inside).
3. I am using Trenchbroom maps as a general map geometry, then I place more detailed 3D meshes on top of that (like trees, clutter, intractable objects) and I cull those objects instead (do not render them nor animate them when they are outside the camera frustum), because the map itself has a really small footprint on memory (usually few-several thousand triangles), so in itself it does not affect much - instead I focus on optimizing animations and more detailed meshes.
4. The other goal for me was to be able to stream a map file from a back-end server. Trenchbroom map format pretty much allows the parser to read map line-by-line as it loads from the server and parse it. Usually the parser is able to process the map as soon as the next chunk is downloaded in a streaming fashion (so that is another thing that was not present in classic Quake engine games but is a concern for me) - I was taking in account the fact that the map has to be downloaded from somewhere before it can be interacted with. It would be much harder if map was provided in a binary format.

So in general it's much more suited for games with top-down view. The general idea is that it's really simple to make a general map geometry in Trenchbroom and then make it look good with additional meshes on top of it.

From what I saw so far Trenchbroom map geometries are usually so simple that it would be hard to make them a bottleneck in a game played on a modern device (I might be wrong about that though :) I saw some Trenchbroom Quake maps that are really impressive, this was never the case for me though as I never attempted to create more complicated meshes like trees or character sculptures etc in a Trenchbroom - instead I use external models for that).

It is possible to add some FPS-specific optimizations to this parser (like regions and proper BSP tree), because you can ask it to just produce faces and blocks and do not merge them into a map, but I just didn't have a need to do so yet - so the potential is there.