Infmap2

[minor pivot]

@sudden plover & I have been working on the following for the past year or so.

The overall goal of this project is to productionize infmap and to develop a tool that is less tech demo and more a legitimate tool that mappers can use to create maps that are:

1. at least 8x8km at 1m resolution
2. can mix and match the fidelity and detail of hand-mapped geometry via Hammer with the scale of a large terrain

We think we're on our way to achieving this by:

• improving performance - so far we've gained 5-10x the performance on the client renderer and O(n log n) to O(n) amortized for serverside teleportation)
• Improving and standardizing the API
• Generate LODs for chunks
• PNG16 floats for heightmaps
• 64-bit chunks allowing travel up to 450 light years in any direction
• Create a set of tools for mappers so that they can:
  • Embed heightmaps and textures (via a tool like WorldCreator) into their maps
  • Stitch hand-mapped elements via the infmap_vbsp entity, which is how I have a spaceship embedded inside the terrain (and the WIP airbase)
  • Permit a minimum of 8km x 8km terrains at 1-meter resolution.

Still WIP, but once we're both happy with it, we'll share it more widely.

Can I also thank @spare sonnet - were it not for Hammer++ and the Propper work he's done, this would be miserable. And also @midnight bronze who has worked on an improved version of networking that, whilst this doesn't rely on it, will ultimately offer significant performance gains if plugged in to it.

To be clear:

• The map above is 8km in every direction. The terrain itself was generated using World Creator. We are using the heightmap, AO, and color exports to generate it. It's a pretty lame texture right now because we assumed we'd have to rely on splats and 2-way blends, but we've discovered the full colour maps are very, very doable.
• The spaceship - when you are inside the chunk, it is standard Hammer geometry (including PVS culling etc). The exterior is a model generated via Propper (and a fairly outdated one at that). For perspective, the ship is about 10000x10000x6000 units.
• The little airbase is still heavily WIP, but again, this is a combination of a Propper model (for the LOD when outside of the chunk) and garden variety hand mapping.

[pale lance]

nice

[green plover]

Oh, i love that. I wonder if this could be used to create "dimensions"? Say, instead of embedding flats into a building, you could just allocate a "dimension"/dedicated space with just this flat somewhere and get the the player onto there. The inner workings seem similar (at least, so i would say on the surface), so it seems possible

[crisp fjord]

Very, very impressive work

[crisp fjord]

Can you explain a little bit about how the Hammer map's contents are used to get the final result?
I'm curious about what parts move and what parts don't.

[minor pivot]

@sudden plover made a video that can explain how it works very well - https://youtu.be/NPsxeRELlNY

So nothing "moves" from a Hammer sense

From the perspective of a mapper, the way it works is you create a hollow skyboxed cube - the larger the better

Like so. Inside that cube is an entity at the centre are a pair of entities - and "infmap" ent" (which has to be at the exact centre) and an "infmap_heightmap" ent.

This is where terrain chunks will be spawned.

The size key in infmap is the perimeter of the box - it should be a little smaller than the surrounding box. When the player hits that perimeter, they'll be teleported back to the other side (think a little like Pacman), their chunk position will be incremented (0 0 0 to 0 1 0 for example), and Infmap will re-render the terrain and regenerate any collisions

The heightmap path inside the infmap_heightmap entity is a path to a PNG16 heightmap image that is used to generate the terrain.

For embedding mapped elements like buildings etc, it's a little similar: you create another block somewhere else in Hammer, map as you would normally, and then add a trigger entity called an infmap_vbsp

Chunk is what chunk it should appear in, and coordinates is the normal Source coordinates to offset it by

So in my example here, when players walk into chunk (22, 6, 3), within the bounds of that trigger, they will be teleported into this space, giving the illusion that this is embedded in the map

For making it visible whilst you're outside, we have the infmap_lod entity

For all intents and purposes, it's a prop_dynamic

My flow is:

1. Create a terrain via Worldcreator
2. Convert the AO and Color Map into a DXT1 texture via MareTF
3. Export the heightmap as a PNG16
4. Take the exterior of any VBSP geometry and create a model of it via Propper
5. Create an infmap_lod, pointing to this model

[crisp fjord]

Those are very interesting details

Could that ship be made to move by having players render it in a different location than it's actual location?

Being able to fly ship of that size and scale around an actual environment would be very cool

[grizzled shore]

Does the stitching part mean you can add a part of one .bsp to another? The biggest drawback I found with the original InfMap is that you can't handle entities and I/O logic outside of map bounds. Being able to merge actual brush maps into one would be a godsent

[minor pivot]

That's the plan

[minor pivot]

Define merge? As in can we file.Read BSP and generate a mesh from it? Not right now, no, and unlikely to be on the roadmap; I think we'd hit collision issues pretty quickly

Can you take two existing VMFs - say, a HL2RP city, a canal map, and Nova Prospekt - then stitch them together with an infmap in between them? yes

Within the bounds of Hammer limits

[minor pivot]

I think so yeah, though you wouldn't necessarily need infmap for this

perhaps that is something we should consider though