Announcement: SEED system

[rich_is_bored]

You don't need a megatexture lite. Megatexture can be used in TDM. All that was missing from Doom 3 was a vfp program and a tool to create the megatextures. You can get both here...

 

Doom 3 Megatexture Mod

 

Megatexture Tool

[nbohr1more]

Ok...

 

Megatexture is a broken-record topic around here but I've never heard that it just requires "ONE vfp file" !!! (and megatexture editing experience of course).

 

I was under the presumption that this was a HEAVY amount of hacking and SDK work and would take months to integrate into TDM (if at all).

 

So I decided to crack open the PK4 and low there was indeed really just one distinct vfp file in Glprogs. The Megatexture.vfp doesn't seem to have any relation with the test.vfp that was included and indeed replacing the contents of Glprogs with JC Denton's \ Ruiner Mod's HDR-Lite the mod still works. Meaning that you don't have to modify the Interaction.vfp to integrate it, it is a standalone vfp.

 

I guess the possible objection is that it's 42 more shader instructions but these seem to run outside the "unified interaction" framework. It really didn't seem to have any detrimental performance from what I could tell either.

 

You could simply plop this megatexture.vfp into glprogs inside tdm_base01.pk4 and be done with this recurring "megatexture topic" as far as I'm concern. Of course the texture size can be astronomical for inclusion with missions but even smaller "mega"textures could be useful. Enterprising authors could use it if desired.

 

What am I missing here, there doesn't seem to be any big technical hurdles, Id and this mod-team already did the work?

[New Horizon]

What am I missing here, there doesn't seem to be any big technical hurdles, Id and this mod-team already did the work?

 

This has been around since 2007, but you need to read the fine print. The megatexture in Doom 3 is not the megatexture from Quake Wars. It's John Carmack's unfinished, proof of concept.

 

The megatextures fro this mod are huge compared to the completed megatexture tech for Quake Wars.

 

* Terrain scale is ~2/3 of Quake Wars maps.

* Megatextures in Quake Wars are 32768x32768, but in this mod can only be 2048x2048.

* The 2048x2048 Megatexture in this mod

would have been 2MB in Quake Wars and not 22MB like in this mod.

 

I honestly don't see this being a huge bonus for TDM mapping. It's an unoptimized proof of concept. It's beta and not really suitable for use in TDM.

 

 

I guess the possible objection is that it's 42 more shader instructions but these seem to run outside the "unified interaction" framework. It really didn't seem to have any detrimental performance from what I could tell either.

 

The other objection is that it's only 2048 x 2048, and 22megs instead of 2megs. So it's not very high res enough to cover a large area of terrain, and it's also unable to be compressed to 'real' megatexture file sizes.

[nbohr1more]

There is no 2048 limit, I just baked a 16kx16k texture using the Megagen tool but it is 1.33GB

 

So there's no size limit other than your hard-drive capacity (and the limits of common sense).

 

Sure the sizes are something to balk at...

 

 

OTOH how would this compare to creating large texture sheets with DDS?

 

You could potentially merge large swaths of various textures and have nearly all materials in a scene call the same megatexture.

 

 

For me, it's just another opportunity to ring the promotional bell shouting "Hey, The Dark Mod now has Megatexture support!"

 

You could make it available to mappers on the stipulation that their missions would be too large to host and only one or two missions with megatexture might be good enough to make an exception.

 

And I'm sure almost nobody would use it to add their own custom megatextures because of how cumbersome the baking process is. But it would be there in your Glprogs folder not harming anyone so you could claim to have megatexture support.

 

Even when Doom 3 goes GPL it's hard to say if anyone will be able to add "true" megatexture support as I don't think that it's an open format. The compression\encoding would have to be reverse engineered. It's more likely, if anything, that an alternate version of megatexture would be created.

[New Horizon]

There is no 2048 limit, I just baked a 16kx16k texture using the Megagen tool but it is 1.33GB

 

I know there isn't a limit. My point was that a 2048 x 2048 texture is 22megs with this implementation vs. 2 megs with the finished Quake 4 megatexture.

 

Even when Doom 3 goes GPL it's hard to say if anyone will be able to add "true" megatexture support as I don't think that it's an open format. The compression\encoding would have to be reverse engineered. It's more likely, if anything, that an alternate version of megatexture would be created.

 

Mega texture is really more beneficial for games requiring long stretches of terrain without obviously repeating textures. We don't really need that for TDM type missions. Why would we want to make a big deal out of announcing that TDM can do megatexture when it's really of limited benefit to us, especially in this unfinished form in D3.

 

Also, it's not so much that they weren't able to figure out how to compress the textures into the smaller mega texture format, they can do that by using the Quake Wars tools...it's more a matter of the Doom 3 engine not being able to support the Quake Wars generated mega textures.

 

What would be far more beneficial for TDM would be 'batches and texture sheets'.

 

http://wiki.splashdamage.com/index.php/Batches

[Tels]

What would be far more beneficial for TDM would be 'batches and texture sheets'.

 

http://wiki.splashdamage.com/index.php/Batches

 

I think this might be possible to hack in, afterall, the ModelGenerator can already build any model it wants, and it could theoretically also build and material shader it wants (I had some ideas where this was needed, but never finished it because it wasn't really nec.), AND we could also generate any TGA file (think: texture) we want.

 

So you could take one func_static, and build the texture for all parts as one combined texture, create a material shader for it and then go for it via and automated texture atlas. And do this at runtime e.g. map load.

 

However, this only works if all the shaders have a common setup - this might work f.i. for wall textures, but as soon as one of them is noshadow/shadow, or transparent, or has an extra spec map or any other small difference in the shader, it would get a bit more involved.

 

Whether this would really bring that much is in doubt, tho. Real geometry instancing (e.g. not just replicating models and clipmodels by copying them around, but by just re-using the existing model and then tell the GPU "clone it") would bring us MUCH bigger benefits IMO, because it would also reduce memory consumption.

 

Texture atlases will increase memory consumption (the same texture can suddenly part of multiple atlases).

 

Edit: Finishing the existing SEED system would probably be a higher priority, anyway.

[New Horizon]

Yeah, I wasn't suggesting it was something we should look into implementing, just that it would be more beneficial to TDM style missions.

 

Once D3 is open sourced it should make optimizations like this much easier.

[Sotha]

I happened to have a small amount of free time and decided to try and learn to use SEED.

 

Basically I have made a simple patch grass with a few tombstones and a small mud path.

 

Like this:

 

I have the entire thing covered with a seed entity.

Inside the seed entity there are 8 models which I want to be randomly placed in the area of the seed covers. I want them to be

• floored to the patch with sinking of 0-2 units.
• Appear only on the grass, maybe on mud with low probability. They should NOT appear on the tombstones.

SEED entity has the following spawnargs

target1 seed_model1

...

target8 seed_model8

remove 1

max_entities 40

floor 1

sink_min 0

sink_max 2

seed_material_grass 1

seed_material_dirt 0.2

seed_probability 0

 

 

My end result looks like this:

Bad:

• Only one variant of the model gets spawned. That changes upon map reload. There are never a variation between the models I targetted from the SEED. I mean that only one kind of bush is spawned all over, not variation with all the bushes, mushrooms and stones
• Some of the models appear on the tombstones, but shouldn't the seed_material_x prevent this?

Hilfe, bitte?

 

EDIT: changed all the func_static models into LOD object entities, but the problems still persist.

 

EDIT2: I was able to fix the entities spawned on the tombstones by just making the seed entity-box smaller, so that it covers only the grass.

 

Running out of time, giving up for the time being.

[Tels]

Hilfe, bitte?

 

Sorry for the late reply, Easter time with family and no net connection.

 

The "only one model spawns" is likely because you put

 

"max_entities" "40"

 

on the SEED entity. This means it selects one class at random, places 40 entities, then runs out of entities to place and gives up, never reaching the next class.

 

Remove that spawnarg and instead adjust the

 

seed_density

 

spawnargs on EACH of the targetted entities instead to tweak their numbers.

 

EDIT2: I was able to fix the entities spawned on the tombstones by just making the seed entity-box smaller, so that it covers only the grass.

 

This is very likely this bug: http://bugs.angua.at/view.php?id=2614

 

Basically, the code uses a "line trace" to determine the material under the entity, which hits the grass right next to the tomestone. Then it uses a "box trace" to place the model on the ground, but the box collides with the tombstone and the entity is placed in midair, hovering or sitting on the tombstone.

 

Another possibility is that if you just place a bush model as target, then it misses all the "seed_material_stone" etc spawnargs that tell the code not to plant bushes on stones (SEED doesn't know that you model is a bush, and not f.i. a rock

 

Edit: I see that you wrote that the SEED entity has "seed_material_grass" etc. These spawnargs need to go on the target entities! On the SEED itself it is atm not possibible to set these as defaults (that should probably tracked as feature request. Also it would be good to add a tracker entry that says that if "seed_somethign" appears on a SEED entity, a warning on the console is given to alert the mapper (possible even throw an error to avoid that such maps ship)).

 

Does this help?

[Sotha]

Does this help?

 

Thanks! Sounds good at least. I'll give it a try once I get home if I have time.

[Shadowhide]

there is demo map featuring SEED ?? where I can download it ?

[Sotha]

@shadowhide:

This is a personal test map, I don't know if there is a SEED showcase map. The newest version of Knighton Manor has some basic SEED usage, though.

 

@Tels:

No luck.

 

What I did was:

• I removed all the seed_material_grass and seed_probability entries from the SEED entity. I put them into the seed func_statics that target the SEED entity.
• Since the seed_density spawnarg defaults 1.0 I didn't give this spawnarg to the func_statics
• I removed the max_entities spawnarg from the SEED entity.

Now the game crashes upon map load. Always. If I put the max_entities back to the SEED entity, the map starts properly. (NOTE: I've always dmapped between map build changes.)

 

EDIT:

Now I got it to work:

• I removed the max_entities spawnarg from the SEED entity
• I gave all the targetting seed func_statics the spawnarg seed_max_entities 20

No crash, versatile seed models, no models on tombstones. Perfect result. Screenie within few moments once I get the seed_max_entities value tested so that it looks the best..

 

EDIT2:

Got a strange bare area in my vegetation. I think it is because the SEED entity is too low. I increased the SEED entity height and the bare area is gone, but the vegetation appearing on the tombstones issue re-appeared. I'll apply some noseed next..

 

EDIT3:

Nope. Not feasable, I'd need to make 15 noseeds to protect all the models from the vegetation. Trying to find optimal seed entity height instead. It feels important that the seed entity ground dropping bug is fixed, hopefully a solution can be found.

[Sotha]

Okay, it was quite easy to find a good height for the SEED. Now there is no more things going on top of the tombstones.

 

Here's a screenie with SEED thingies:

r_showprimitives says:

views: 8, draws 497, tris 169 369, shdw 11 458, image 50,6mb.

 

 

 

 

And here is the view without SEED:

r_showprimitives:

views 8, draws 412, tris 33 216, shdw 10 522, image 48,2mb.

 

That's a lot more tris, but visually SEED scene looks much much more interesting.

[OrbWeaver]

Something doesn't look right with those statistics. Surely a few simple vegetation models can't be using 130k triangles?

[Sotha]

Something doesn't look right with those statistics. Surely a few simple vegetation models can't be using 130k triangles?

 

Yeah, I was a bit surprised too.

 

The only way how those shots differ is that in the other the SEED entity was deleted. I might be standing on a bit different place but that's how the images and statistics are different.

 

What could be the reason? All the templates are noshadowed, so it couldn't be shadow tris.

 

Since SEED couples all the models, could the game be calculating also the UNSEEN vegetation model tris into that as well? I am standing roughly in the middle of the seed entity, wathing the other way and there are many bushes outside of the player's view in that screenie...

 

Or maybe I simply made a mistake in writing up the results. I doubt it, but I gotta check it.

[Sotha]

Strange. Now there seems to be much lower tris difference. Few thousand. Oh well, I suppose I can blame general incompetence and trying to do things when tired.

[Baddcog]

At one point I think seed was doubling models because of materials with twosided in them. But I think that was fixed.

 

Maybe that cropped up again, but not now?

[Tels]

Strange. Now there seems to be much lower tris difference. Few thousand. Oh well, I suppose I can blame general incompetence and trying to do things when tired.

 

Note that the "bush models" you are using are actually quite bad models, they use I think 200 tris or so, and a low-res texture, so they do not look like a bush at all. So plant a few dozend of them and you can really run up a few thousand tris.

 

Unfortunately, I cannot fix these models..

 

Glad you got it to work, atm I do not have any time at all for SEED, and this will very probably be the case until mid June.

[Tels]

I have resumed working on the SEED code, and as a first step fixed bug #2722:

 

When you place a SEED entity so that it "hangs" over empty air, then the entities that were floored are only floored until the bottom of the SEED entity (actually, depending on whether you used a template or a real entity, the ended up either at the height of the origin of the SEED entity, or the real entity height):

 

 

I have now added a spawnarg "floating" (default is "0") to the SEED entity, and "seed_floating" (also off by default). If "off", the entities will be skipped if they would float, and if on, they will stay at the bottom of the SEED entity:

 

 

This change will appear in v1.07. Until then, please extend SEED entities until their bottom sticks into terrain, or make them smaller so they don't float.

[nbohr1more]

Is it possible to create a Func_Portal entity whose "close distance" is determined via the "LOD Bias" menu choices?

 

 

 

Also...

 

Any chance that Tracker 563 (disable shadow-casting on distant lights) will be looked into for v1.07 ?

[Baddcog]

I really don't think you'd want to close portals by distance based on user settings. When one closes in view you get a large black square. It's very ugly, much worse than a little model popping or shader changes.

 

If you require that then you just need to learn to optimize/portal better.

 

Portals should never be forced closed in view, but they can be forced closed by distance, that's a mapper optimization.

[nbohr1more]

Sure...

 

But with a Func_Portal you can have a texture, cubemap or even remote render map on there instead of the black...

[Tels]

Is it possible to create a Func_Portal entity whose "close distance" is determined via the "LOD Bias" menu choices?

 

I would have to look into the code.

 

Also...

 

Any chance that Tracker 563 (disable shadow-casting on distant lights) will be looked into for v1.07 ?

 

I am to 120% busy with the translation work (e.g. what little time I have goes there). Ask me in a week or two when the translation is hopefully nailed.

[Tels]

Watch this:

 

 

Nice idea, I wish the engine was open source already so I could integrate the rendering much better (than crudely build models by cloning triangles - yuck!)

 

And then this:

 

 

Oh boy, I should just give up

[AluminumHaste]

Watch this:

 

 

Nice idea, I wish the engine was open source already so I could integrate the rendering much better (than crudely build models by cloning triangles - yuck!)

 

And then this:

 

 

Oh boy, I should just give up

 

LOL thanks for posting that, I just spent 30$ on the pre-order just to play the Alpha. Fun game.