Jump to content
The Dark Mod Forums

Announcement: SEED system


Tels

Recommended Posts

  • 3 weeks later...

Location System, Portals, and SEED?

 

All these things can or do use proximity checks.

 

Are all those proximity's managed in the same place in the code?

 

Or is there some redundancy?

 

Could you just add Location System spawnargs to SEED then remove the location system?

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

Location System, Portals, and SEED?

 

All these things can or do use proximity checks.

 

Are all those proximity's managed in the same place in the code?

 

Or is there some redundancy?

 

Could you just add Location System spawnargs to SEED then remove the location system?

 

I'd have to look it up for the distance portals (my mind is getting spotty :( but I am pretty sure it uses the same LOD system. Which I inserted into all entities, and it is in a central place in the code.

 

So whenever you add the LOD spawnargs to an entity (be it light, portal, or func_emitter), they are going through the same routine. The are also all centrally stored and managed because there is a lot of rendundancy in the data - think 1000 clone trees with the same hide_distance etc. - they only use one entry instead of 1000 at the LOD manager.

 

The only difference is between what each entity class does with the data. Normal entities (rendered ones) can hide themselves, or use a simpler model. func_emitters can only hide/show (but not switch between particle models), and lights can do only the "use a simpler model trick" but I am not sure if they hide (e.g. switch off).

 

I'm pretty sure that the possibilities for other LOD entities (e.g. portals) have not yet been explored or tested fully.

"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 Tels.

 

:)

 

It should be possible to replace the light model with the same model with different attributes (like noshadows) so the request to make that part of the LOD system might be excessive anyway. (I'm pretty sure Crispy's comment showed that setting noshadows to lights already has a script event too). So the options are probably there for lights... Thus far Portals are an unknown... :ph34r:

 

Edit:

 

Yes, you can already do a "set shader" script for lights:

 

float lightstatus;

void main(){
lightstatus = 1;
}


void changelight(){
if(lightstatus){
//this is the shader the light will change to
$light_1.setShader("lights/ambientLight");
}else{
//this part is for toggling the light back to flicker , this should be the same as the shader set in the editor
$light_1.setShader("lights/round_flicker2");
}
//toggle lightstatus
lightstatus = (lightstatus * -1) +1;
}

 

So just choose a light shader with noShadows in the Global section of the material.

 

Alternately, I think this might work:

 

$light_1.noShadows = true

 

???

 

From rebb's code for frame-based shadow removal:

 

 	for( int i = 0; i < gameLocal.curLightEnts.Num(); ++i ) {
light = static_cast< idLight * >( gameLocal.entities[ gameLocal.curLightEnts[ i ] ] );
light->renderLight.noShadows = true;
light->PresentLightDefChange();
}

Edited by nbohr1more

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

  • 7 months later...

Haven't had time to really start working on SEED again, so none of the outstanding issues are solved. And having the D3 source code is nice, but there was zero work on the model manager during the time. And with the freeze of v1.08 getting really close, there is no chance that I will manage to work on any of this. Sorry.

 

However, here is a small thing I just added:

 

Basically, mappers sometimes want to make content appear only for people with faster machines. Using the SEED system, however, is cumbersome, due to the entities being generated in random places. Also, using hiding distances mean everything is rendered if you are close (think hundreds of static entites in a kitchen). Or worse, nothing is rendered if you are far away (think: skybox).

 

So I thought it might be a good idea to have a way to specify for which detail setting an entity should appear - a bit like "for which difficulty setting this entity should be there".

 

The details are described here: http://wiki.thedarkm...?title=LOD_Bias

 

You can tune which "Object Detail" setting makes which entity appear. You can even make it so that one entity (a simple one) is displayed for low-end machines, and another one for high-end machines.

 

As a testmap, I updated the snow map to showcase this feature. If you are using v1.08, you can even toggle the menu setting and return to the map and see the effect live.

 

Here are 4 screenshots, done with the setting on "Lowest", "Low", "Normal" and "Higher". Note that this is just an example, the feature should be used for entities where the player cannot interact with them, and which actually make a difference in performance when visible, or not. In this example, the difference is way too small to affect performance. But it demonstrates the effect. (please ignore the black shader on the glass in the background).

 

In real maps, you could f.i. have a detailed, lit window on the highest setting, a normal, unlit window on the Normal setting, and no window at all at the lowest setting.

 

post-144-0-99885500-1336313546_thumb.jpg post-144-0-15019200-1336313558_thumb.jpg

post-144-0-35962500-1336313570_thumb.jpg post-144-0-40352600-1336313596_thumb.jpg

  • Like 1

"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

In real maps, you could f.i. have a detailed, lit window on the highest setting, a normal, unlit window on the Normal setting

 

Cool! Would it also work for transparencies? So you could have a transparent window with a scene beyond for high settings, but block it with a solid window for lower settings?

Link to comment
Share on other sites

Cool! Would it also work for transparencies? So you could have a transparent window with a scene beyond for high settings, but block it with a solid window for lower settings?

 

The code just hides entities if they are outside the range, so technically, you could hide the transparent window on the lower settings and replace it with a solid one - but I think the stuff behind the opening will still be drawn because there is no visportal. So you'd also need to mark the stuff behind the window to be hidden, which only works if the player can never access the area.

 

(e.g. it would work if this is f.i. a garden you can look out to, but never go to.)

 

So, hm, we'd need a new entity, that if visible, tells a visportal to close.

 

I am not sure what happens if you make a visportal brush an entity, does this even work? I am gonna try this :D

"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

It looks making a visportal an entity does indeed somewhat work, but it stills draws a black cube. However, I think that with a bit of making func_portal can be used - e.g. it closes/openes the portal depending on wether the min/max lod bias values are in the range, or not. If then combined with an entity that "covers up" the closed visportal (so you don't see the black area), it could work. I'll report back when the compile is finished (god I hate the 16 minute delay....)

"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

You'd need a v-portal in that case anyway, so all you'd need is a setting to make the vp close due to being an opaque window.

 

What about a case where that window is useable by the player though. Then it would be a door and would autoclose the portal, but if you had transparency you'd want it to stay open.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

You'd need a v-portal in that case anyway, so all you'd need is a setting to make the vp close due to being an opaque window.

 

Yes, but if it was that easy, we'd have done it before :P

 

What about a case where that window is useable by the player though. Then it would be a door and would autoclose the portal, but if you had transparency you'd want it to stay open.

 

I have something in the pipeline that will fix the first case. The second one I am snot sure, does this even work right now? A door with a glas window and an ever-open visportal? How woudl one build such a thing in DR?

"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

After reading the whole Doom 3 "Virtual Texture\etc" thread and the last few replies about regular texture streaming, I thought about the SEED system again.

 

I am wondering if you could setup a distance threshold where textures in the map would be replaced by dynamic internal images like "_grey" etc. Since the full

source to the map loader is in place would such a thing be on your radar?

 

(Of course, the new Normal Map compression code\format already helps address this same concern.)

 

As far as the map geometry data, I am presuming that would be much more complicated to "stream"... :D

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

Sorry, since the linu xbuild system is broken, it takes me hours waiting for simple changes to compile. (I spent nearly two days for this simple feature, which should have no taken longer than an hour or two).

 

Plus, currently TDM doesn't like to load D3 assets on linux, for whatever bizarre reason. So half the lights and particles are broken etc.

 

This is very likely one of my last code contributions, unless someone finally fixes the linux side again.

"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

I have extended the lod_bias feature by two things:

 

* instead of getting hidden, func_portals now will close their associated portal (the one they touch) when they are outside the min/max range, and open it, if they are inside. Thus you can now have certain visportals open or closed, depending on quality setting

* if the spawnarg "lod_hidden_skin" is set on an entity, it will not get hidden (outside the min/max boundary), instead if will get this skin, and if inside again, restore the original skin

 

This makes it possible to build windows that are either close (opaque), or semi-transparent (open), depending on the menu setting. Changing the menu setting will reflect that change once you exit the menu and return to the map, so it is easily possible to test it in realtime.

 

The snow map has been enhanced with an example. You need:

 

* an opening in a wall

* a visportal in it

* a func_portal touching the visportal

* a func_static window, with an appropriate skin set

 

Here is "Normal" quality:

 

post-144-0-85748400-1336335138_thumb.jpg

 

And here with Higher:

 

post-144-0-54157300-1336335173_thumb.jpg

 

Here is a tris view:

 

post-144-0-29322600-1336335195_thumb.jpg

  • Like 2

"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

This can make people on both sides of the performance scale happy. It's a great feature, Tels. Good thinking.

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

  • 1 year later...

Looks neat. Know about FMs that use SEED and/or LOD bias?

 

EDIT: so that I (and who's willing to) can get some clues about good practices.

Edited by Bastoc

Jared, is that you ?

Must be rats...

Link to comment
Share on other sites

I've used the seed system in my FM the Builder Roads. The grass on the outside was made using this system. For grass there is actually a predefined entity handling this. It can be found under Randoms. In addition you can check the wiki. Search for SEED and you'll find the wiki articles written by Tels, explaining how to use the SEED system.

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

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...