Concept Idea

[toneddu2000]

Hi guys, I'll put in here, because I'm not sure what I've to do is feasible in QuakeC. I'm creating a tech demo on FTE (and MAYBE DP) and the goal is to build an environment where player[s] advances in a real time generated dungeon. I imagined a 512 units side grid. In every grid cell I spawn a random hull mesh (with walls,floor and ceiling). As you take a look at I just realized you see the red cell is where player is, yellow cells is proximity hulls that MUST be shown, azure cells are very far and maybe low LOD's and grey cells shouldn't be renderer, because the ambient light would be 0 with only a dinamic light tied to the player. So basically it's fuXXXng dark.
All the player and monsters code(Weapon, movement,AI, physics) will be made in CSQC but imagine the "random generated level cells" part should be done in SSQC. Do you think is doable with qc or is it a C work? Anyone was involved in something similar before? There's some open source code I can steal?
Thanks in advance

PS: orientation (connections of doors and stuff) of hulls cage is still WIP, it don't even bothers me right now!

[frag.machine]

Heh, what can I say ? Yeah, it's totally possible, because that's pretty much the project I'm working on for some time: a procedurally generated open, persistent, partially destructible world composed of 256 interconected "sectors" (in a toroidal configuration as you would see in a Zelda styled world) each one composed by 256 square "cells" with 512 qu side in a 16 by 16 grid.

Everything generated by QuakeC, and being persisted using FRIK_FILE (so far the only required engine extension, so the concept should work in most modern engines). I even posted some shots and a video or two from an early prototype (it's in the 5th incarnation now) in the "what are you working on?" thread.

Every sector has a main theme (right now identified by color only in mock models, I scraped all artwork I used before and will focus on this later) and two complimentary themes so the adjacent sectors kinda "blend" in a non abrupt way. I'm off my computer right now but I suppose it's time to post some update on this later.

[toneddu2000]

[frag.machine]

[toneddu2000]

[frag.machine]

"Persistent" as in there's a "data" folder in the mod folder where I will store the sector contents every time the player "travels" to another sector. If the destination sector was never visited before, it's generated on the fly, otherwise is just read from a data file (one file per sector). So yeah, you can play today, stop playing, and resume one month or one year later in the exact point you were.

Also, the link to the project thread.

[Spike]

http://www.daemonforge.org/?i=rlyehcity is another dynamically-generated content mod (for dp).
and of course, the fore-runner - frikac's bigmap mod. okay, so it has a different aim, but other than the random generation the rest is basically the same.

if you're generating the map truely dynamically such that multiplayer is screwed, perhaps you should consider ditching ssqc completely? in fte, you can set 'pr_csqc_formenus 1' and make a full single-player game without ever connecting to a server (note: I ought to test input in this mode), while dp will have to make do with a stub ssqc. not having to relay entities from ssqc all the time would help simplify the game. demos will be screwed completely, but that was bound to happen anyway when your ssqc doesn't do anything.

[toneddu2000]

[frag.machine]

Yeah, all those unVISed BSP entities can easily make a decent machine to crawl (let alone more modest/older hardware). This is far less problematic in topdown/isometric perspective though.

[Spike]

tbh its large unvised rtlights that really kills framerates in that mod.

[toneddu2000]

[qbism]

Rtlights are probably the only good-looking way to light models in a qc-generated environment, unless bsp model lighting, tile spacing, and lighting of the world floor align on a grid. This is because alias models (like monsters) are illuminated based on the pointlight of the world below and not the floor of the bsp model they're standing on.

[toneddu2000]

indeed, infact I'll use only RTLights, my only doubt is if it's possible to create through shaders a "vis cage" around the light and the portion of meshes it can lit, so to optimize lighting and frame rate (pardon my raw terms)

[Spike]

with a q3bsp shell thing, you could chop the world into an 8*8 grid of 'areas', with some entity sitting between each two areas. you can then use the openportal builtin to open/close the portal between the two areas. if the portal is closed, vis is blocked too. lights behind the portal will no longer be drawn. this is what q2/q3 use on doors to dynamically close the pvs.
the 8*8 grid is because there's a limit to the number of areas you can have. in theory I could boost it to 256*256, but that's a loooot of memory, and even more entities to track the portals (though I guess with q3bsp you could just use setorigin to find the two areas dynamically, which might help reduce the number of entities).

[toneddu2000]