Jump to content
The Dark Mod Forums

Announcement: SEED system


Tels

Recommended Posts

Hello together,

 

as some of you know, I started back in June/July 2010 a project to bring two things to Doom3:

 

* LOD - Level of Detail (where objects change their visual appearance based on distance to the player)

* SEED - procedural, semi-random content generation

 

Please do not confuse LOD with the SEED - they are sep. systems, where the SEED system can use LOD entities, but also just normal, static models.

 

The wiki articles above should explain these topics and their usage, but if they don't do this properly, or there are questions, please ask them here.

 

Below I will go into some more details for the SEED system and explain what it does, and how/why you as a mapper should test it.

 

Some remarks:

 

* the LOD system was disable some hours before release, because there was a bug in it. Unfortunately, the disabling was wrong, too, and took out the entire LOD system instead.

* the SEED system itself works, but:

 

** someone took out the main menu control ("Object details") and it seems it didn't even make it into v1.03 :(

** It crashes on load/save - which means as a mapper you can test the system, but not release missions with it before v1.04

** The Model combiner is too slow in case the models have twosided or shadow casting surfaces - it might take up to 1/3 of a second to recombine models (with many faces). This will eventually be rewritten, so the performance will get better

** In TDM v1.03, the systen is still called "LODE" and all "seed.*" spawnargs are named "lode.*".

** In TDM v1.04, a lot bugs will have been fixed, the performance improved etc.

 

However, having said this, it works and I encourage you to test it. If you have any questions, please post here.

 

The next post will go into more detail.

 

Edit: SEED is the new LODE, go with the times. :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Here is a short overview on what the SEED system does:

 

* themapper creates an "area" (atdm:seed entity covering that area)

* he then also creates "templates" (entities or func_statics), then links them from the SEED

 

When the map starts, the SEED entity does:

 

* take the templates, and create "positions" from these

* it then combines as many entities at these positions into one entity (to save drawcalls)

 

The system is suited mainly to vegetation, rubble, decoration or anything where many models should appear, but their exact plaement isn't importantn (or it is actually important that they ar all different).

 

The "placment" of entities can depend on:

 

* a global distribution formula (think "circle")

* the ground texture (think: "no grass on metal or stone")

* modifiers (think "no trees beyond X units height")

 

and can be of course adjusted for each template seperatedly.

 

The player can (sadly only from v1.04 onward) choose how many of these entities/models should appear. On a slow machine, use "Lowest" and you end up with only a few grass or mushrooms, or only a few pieces of garbage. On a fast machine, use "Highest" and you end up with dense vegetation, or much rubble.

 

Screenshots in the next post:

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

A few 10000 grassbushels, all planted automatically, the distribution follows image data (loaded from a TGA file):

 

post-144-129396791691_thumb.jpg

 

A few 10000 mushrooms, showing the distribution formulas at work:

 

post-144-129396797614_thumb.jpg

 

Rendermodels randomly scaled (the clip models do not yet scale, so this works only for non-solids like vegetation or far-away decals):

 

post-144-129396802531_thumb.jpg

 

Showing that func_statics (which on DR can only be copied) can be combined into one model, and still each have their own clipmodel:

 

post-144-129396807167_thumb.jpg

 

And to wet your appetite, my pond testmap:

 

In the editor:

 

post-144-129396812766_thumb.jpg

 

In the game:

 

post-144-129396810154_thumb.jpg

 

Note: This are over 11000 models, something impossible with TDM 1.02 alone (there is the 8192 entities limit), and about 1.4 million tris on the screen. The performane isn't good (due to too many tris), but with better grass/bush models and a few more tricks this can be reduced greatly. I had to work with the models we go at this time.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Here is another screen, showing debug colors at work (all models combined into one entity get the same color):

 

post-144-129396848925_thumb.jpg

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

A lot of detail to read so later. I assume LOD only works with models but would the LODE work with func_static patches entities as well as models? I'm just wondering this might look good with the ground cover textures as well. Say a large expansive patch or model terrain of earth, stone, grass whatever, manually covered with many very large ground cover leaves patches plus a lot more smaller patches of the same (probably varied leaves and colours) spread throughout. Plus other stuff of course like trees.

Link to comment
Share on other sites

The player can choose how many of these entities/models should appear. On a slow machine, use "Lowest" and you end up with only a few grass or mushrooms, or only a few pieces of garbage. On a fast machine, use "Highest" and you end up with dense vegetation, or much rubble.

 

Can the mapper over-ride this? As a mapper I'm not sure I want the player controlling how many models are there...if it's important for an area to be dense vegetation (as a random example), then I don't want players turning it into mostly empty ground. Beyond looking bad, that could have a direct impact on gameplay, couldn't it (if it were used for shadow-casting trees, for example)?

Link to comment
Share on other sites

LODE sounds cool.

 

  • Place created entities on random positions with random rotations (and random vertex colors)
  • Only creates (spawns) the entities that are "near" the player (saving memory and CPU time)
  • Removes entities "far" from the player, thus overcomes the entity limit

 

So if the player is outdoors and the vegetation around him is autogenerated and autoremoved when he is near, will the vegetation be on the same spot once the player returned to a same point? Or will the plants location be rerandomized when the player returns? Or will positions be fixed at each map start?

 

 

 

Useful for:

 

  • putting in random crates, barrels and junk into basements

 

Are these random objects just func_statics? If so, will the system monsterclip them so the AI doesn't have difficulties passing through? Or are they moveable? I've not tested random generation, but intuition says only really small items should be placed with that so that AI's do not get stuck, etc.

 

Random loot placing is also nice, but not very important, since if the player always finds some loot at a certain location: I do not see it is very important for the player what trinket exactly the loot it is.

 

The system is new and all the potential is gonna be realized just later. Can you think of some more general mapping advantages of LODE? I mean that it obviously is required for big missions (entity limit) and missions with exterior vegetation (forest maps performance), but can you see some benefit for current small, mostly interior, FM's we have?

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

A lot of detail to read so later. I assume LOD only works with models but would the LODE work with func_static patches entities as well as models?

 

Yes. By "func_statics" I mean anything that either has a model (ASE or LWO), a brush-turned-func-static, or patch-turned-func-static and the brushes/patches can also be mixed.

 

I'm just wondering this might look good with the ground cover textures as well. Say a large expansive patch or model terrain of earth, stone, grass whatever, manually covered with many very large ground cover leaves patches plus a lot more smaller patches of the same (probably varied leaves and colours) spread throughout. Plus other stuff of course like trees.

 

I have used it to "plant" rocks/stones on the ground, and this looks good. One can't overdo it, tho, but if you simply leaf decals or something, it can look convincing enough. (Also, making many models use the same shader (with different "areas" painted on) can improve performance.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Can the mapper over-ride this? As a mapper I'm not sure I want the player controlling how many models are there...if it's important for an area to be dense vegetation (as a random example), then I don't want players turning it into mostly empty ground. Beyond looking bad, that could have a direct impact on gameplay, couldn't it (if it were used for shadow-casting trees, for example)?

 

Yes, he mapper can specify a spawnarg that says "the minimum item number that is affected by the menu is X" and the default for this is 16 (or 10, I forgot). So if you have a lode generating 3 trees, you will always get 3, regardless of menu setting. But if you have it generate 100 mushrooms, you end up with 75, 85, 100, 110, 120 depending on menu setting (I forgot the exact numbers, would have too look them up, but SVN is down).

 

The basic idea is: "test you map with the medium and smallest/biggest setting and see how it looks". In a lot of cases, the number of flowers, rocks, grass etc doesn't actually mapper, but more usually looks better, and less usually renders faster.

 

Edit: I wanted to add screenshots, but need to make them first.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

So if the player is outdoors and the vegetation around him is autogenerated and autoremoved when he is near, will the vegetation be on the same spot once the player returned to a same point? Or will the plants location be rerandomized when the player returns? Or will positions be fixed at each map start?

 

The positions will be fixed during map start. So each replay of the map will appear different, but when you save/load a map, or leave the area, and then return, the area will look exactly the same, down to each flower being in the same spot.

 

The "culling" of entities if the player is near is, btw, independent of the LODE system, you can also set it up so that things don't get culled at all.

 

Are these random objects just func_statics? If so, will the system monsterclip them so the AI doesn't have difficulties passing through? Or are they moveable? I've not tested random generation, but intuition says only really small items should be placed with that so that AI's do not get stuck, etc.

 

The system works with moveables (even when the player moved them, they will stay where they are, even if they are culled), but beyond a few tests I have not really stresstested the system.

 

Also, the inetraction with AI is not really tested. The monsterclipping is somethign to consider (maybe even auto-monsterclip might be implemented). For now, you can f.i. create a monster-clip for some forest, so the AI doesn't enter it.

 

Random loot placing is also nice, but not very important, since if the player always finds some loot at a certain location: I do not see it is very important for the player what trinket exactly the loot it is.

 

It might add replay value. Instead of always finding a vase, he might find something of the same value, but looking different each time.

 

The system is new and all the potential is gonna be realized just later. Can you think of some more general mapping advantages of LODE? I mean that it obviously is required for big missions (entity limit) and missions with exterior vegetation (forest maps performance), but can you see some benefit for current small, mostly interior, FM's we have?

 

There are f.i. pre-made entities that spawn random food. Drag them to the size you want, specify the number of items, and it will spawn random food entities with random skins. The result is that it looks slightly different whenever you replay a mission.

 

Likewise, something like this could be added for generic rubble. Mappers might find it tedious to "dirty up" areas, with a pre-made "rubble" entitiy, you drag it into place, specify the density or entity count, and you are done. Each player will get a different heap of trash upon mission start.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

The positions will be fixed during map start. So each replay of the map will appear different, but when you save/load a map, or leave the area, and then return, the area will look exactly the same, down to each flower being in the same spot.

 

Maybe it would be a useful if the system allowed setting a certain random seed value per "LODE Node", so the positions are randomized, but still the same for a certain seed number. Would that be possible / make sense ?

Link to comment
Share on other sites

This sounds like it will be revolutionary! Really something. Great for mappers and great for players.

 

My only semi-critical comment is typical of me: I wish -- because this sounds like it is such an undertaking and will almost certainly need plenty of instance testing {always more than you think and then some... and then some... and then a bit more} -- you guys would seriously consider releasing 1.04 as a 1.03 maintenance + (those just-missed-the-deadline) asset pack. And plan on putting some of the other, more ambitious things into 1.05... I keep saying this because, yes, I'd like to see the missing work that Serpentine and Melan and Nosslak and whomever I regretfully missed mentioning have wrought, AND because by making this move, this "semi-quick-release" the new TDM_Update can be evaluated further for it's functionality in this respect while the implementation of it is fresh (say fresher) in greebo's mind.

Link to comment
Share on other sites

Maybe it would be a useful if the system allowed setting a certain random seed value per "LODE Node", so the positions are randomized, but still the same for a certain seed number. Would that be possible / make sense ?

 

Already implemented:

 

http://wiki.thedarkmod.com/index.php?title=SEED_-_Spawnargs#randseed

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Duuude, this is just awesome looking.. I cant wait to get around to using this at some point in the future..Is that fog or mist I can see btw? and what are your pc system specs ..?

 

Yes, it is "rolling fog" (e.g. the fog moves). My system has 4Gbyte memory, 64bit Linux, and a Geforce 9800GT (512 Mbyte VRAM).

 

The performance of the map is quite bad (abut 2..4FPS) since it are 1.4 million tris and over 1500 drawcalls - so I definitely need to make new models. A few of them (the new cattails) are already there, but I hadn't them used there). Hopefully I will have some more time in this year.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Quite an accomplishment!

 

Not to add to your workload but I think this calls for a LODE version of the Mapper's Startpack or maybe just copies of some of your examples above made available for download.

 

I will definitely be excited to see how things progress by v1.04

 

:D

 

(Will there be a hotfix to re-enable the regular LOD feature before v1.04? :unsure: )

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

(Will there be a hotfix to re-enable the regular LOD feature before v1.04? :unsure: )

 

No, as we haven't had time to thoroughly test it...that's why it wasn't included in 1.03.

 

Now that 1.03 has finally been released, it gives us time to focus on this new feature and give it the attention it deserves.

Link to comment
Share on other sites

The problem is that these both only scale the rendermodel, but not the clipmodel. I do have an idea where one might insert code to do this, but scaling clipmodels is not as easy because their data structure is completely different and I haven't made yet head or tails out of it...

 

More curiosity:

 

So if I read this Doom3world article:

 

http://www.doom3world.org/phpbb2/viewtopic.php?p=151225

 

...and cross-reference this Splash Damage reference:

 

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

 

I see that Collision is not really a traditional Model to Doom 3 per se but instead is always treated as BSP. So unlike the Ground Zero style Vertex manipulation you would need to manipulate BSP nodes to scale the Clip Models?

 

If so, have you found the corresponding internal structure for collison BSP node data?

 

Or is there an internal polygonal data structure (confirming Splash Damage's assertion that Collision is rendered as Polygons rather than triangles...) ?

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

More curiosity:

 

So if I read this Doom3world article:

 

http://www.doom3world.org/phpbb2/viewtopic.php?p=151225

 

...and cross-reference this Splash Damage reference:

 

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

 

I see that Collision is not really a traditional Model to Doom 3 per se but instead is always treated as BSP. So unlike the Ground Zero style Vertex manipulation you would need to manipulate BSP nodes to scale the Clip Models?

 

If so, have you found the corresponding internal structure for collison BSP node data?

 

Or is there an internal polygonal data structure (confirming Splash Damage's assertion that Collision is rendered as Polygons rather than triangles...) ?

 

I am not so sure, haven't read the articles yet. But from the looking into the internal datastructures, and what I remember, the CMs look like "plane + distance from origin" to me. Scaling such a model is complicated, because just moving the plane further away is not correct.

 

One might just scale the undelying model, then create a new CM from it, but AFAIK you can only do "LoadModel()", and this only accepts a model name.

 

The only way I saw is:

 

* duplicate the CM object (easy)

* scale it (no idea how, see above)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Thanks!

 

That does sound similar to the polygon based geometry that Splash Damage alluded to.

 

I do see the issue there. You would need to find four opposite edges of each n-sided plane to calculate the center position so that you could scale outward from the plane center in sync with scaling away from the model origin.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

So, has any mapper ever tried to use this? What are your experiences? Which features do you think are missing? What would you have otherwise or different?

 

If not, would you try it? Make a very small (or huge if you want) test mission, but some LODEs into it and try to model something. For instance a heap of rubble in a corner, a patch of grass, or some group of trees.

 

We need your feedback!

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Back when I posed my thread about LOD models, there was hope that somebody might pick this up and create new models, esp. for vegetation. Seems nobody did, tho, so I had to work on this myself.

 

Here are todays result:

 

* a new "grass_panicle" model (based on this flick photograp http://farm1.static.flickr.com/21/28504527_51a81d2033_z.jpg) (4 tris)

* a new "grass_fuzz" model thrown together in Gimp (18 tris)

 

Here are they ingame:

 

post-144-129451023074_thumb.jpg

 

And with r_showTris 1:

 

post-144-129451025511_thumb.jpg

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...