Jump to content
The Dark Mod Forums

Turning multiple models into one func_static (new feature) ?


Recommended Posts

Would it be easy to add ability to turn several selected func_static models into one? As if you select several brushes and turn them into one func_static.

Maybe having an option like "multi_func_static" "1" in a game config file for DR would enable/disable such functionality to avoid messing with Doom 3/TDM games.

 

We are looking into having several models in one func_static, and if we figure it out, it would be nice to be able to select models in DR and turn them into one func_static.

Link to comment
Share on other sites

func_static models are ASE or LWO, which means they are triangulated. A script could take these and create one single ASE from that, but it's not trivial. There's already one script for ASE export which could be used as basis for it.

 

The main benefit here is reducing the entity count, I assume, or is it easier handling in the editor? Rendering speed is not likely to increase unless the models involved share most of their materials, as the id4 engine does rendering per light and per shader. Also, the single func_static entity has a larger bounding box and is less likely to be culled by visportals or the view frustum.

Link to comment
Share on other sites

There is also the SEED system, which can combine entities for rendering and even cull/respawn entities based on distance and other parameters: http://wiki.thedarkmod.com/index.php?title=SEED

 

It basically does what you want, but at runtime. It has its drawbacks and performance could be even improved, now that we have the source code. But for a lot of cases it can already help.

"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

Entity count and easier scene managing are the goals. Currently making levels a la UE3/4 is not possible because entity count will skyrocket. For example, if I bring in a segment of a ladder, and use it to create several ladders across the level, I will exceed entity count really fast. Same goes for placing decorative models across the level.

 

With func_static supporting multiple models, I could just "group" segments, decorative models and architectural pieces into less func_statics. That would allow for more efficient and more modern approach in level design.

Link to comment
Share on other sites

There is also the SEED system, which can combine entities for rendering and even cull/respawn entities based on distance and other parameters: http://wiki.thedarkm....php?title=SEED

 

It basically does what you want, but at runtime. It has its drawbacks and performance could be even improved, now that we have the source code. But for a lot of cases it can already help.

 

SEED is TDM-only feature. DR is used for many other projects using idTech 4 or derivatives. It would be much easier to add support to Doom 3 for multi-model func_static than port SEED. Plus SEED doesn't solve the issue arising from modular design of the levels similar to UE3/4.

Link to comment
Share on other sites

For example, if I bring in a segment of a ladder, and use it to create several ladders across the level, I will exceed entity count really fast. Same goes for placing decorative models across the level.

 

The problem is that as greebo said, this will completely obliterate the bounding-box-based model culling that the game engine does to reduce draw calls. If all of the ladders in your level are a single entity, then they will be drawn as a single entity even if only one ladder is actually visible at a time. If you do this with a large number of decorative objects you could encounter major performance drops from rendering unnecessary geometry.

 

I think a better long-term solution would be to identify why entity count is actually a problem and aim to fix this underlying issue in the engine so that it can handle the higher entity counts efficiently. If it's a problem only at runtime (rather than in the editor) you could try the "inline" property which supposedly turns the model into regular world geometry, but I have no idea how well this actually works.

Link to comment
Share on other sites

The problem is that as greebo said, this will completely obliterate the bounding-box-based model culling that the game engine does to reduce draw calls. If all of the ladders in your level are a single entity, then they will be drawn as a single entity even if only one ladder is actually visible at a time. If you do this with a large number of decorative objects you could encounter major performance drops from rendering unnecessary geometry.

 

idTech 4 performs per-surface culling, not per entity culling. So you can have one level as one big entity, and yet it will perform the same as if it was a standard-built level. I talked to Brian Harris about this a while ago.

 

Plus, even if the engine was culling on per entity basis, I wouldn't group all ladder segment on the level into one big entity. I would group it per ladder. This way if I had 5 ladders made of 1000 pieces total, I'd have 5 muti-model func_statics, instead of 1 multi-model func_static.

 

I think a better long-term solution would be to identify why entity count is actually a problem and aim to fix this underlying issue in the engine so that it can handle the higher entity counts efficiently. If it's a problem only at runtime (rather than in the editor) you could try the "inline" property which supposedly turns the model into regular world geometry, but I have no idea how well this actually works.

 

"inlining" is broken in Doom 3's version of idTech 4 (no collision models being generated, entity remains on the map) and also it bloats .proc file.

 

If entity limit is fixed somehow, managing massive amount of entities in the editor is still an issue, since there is no way to combine func_statics inside the editor (layers are quite inefficient for that purpose).

Link to comment
Share on other sites

idTech 4 performs per-surface culling, not per entity culling. So you can have one level as one big entity, and yet it will perform the same as if it was a standard-built level. I talked to Brian Harris about this a while ago.

 

Interesting. That is certainly an obvious and sensible optimisation to do if models might be made up of multiple surfaces, so I guess it's unsurprising they implemented it that way.

 

Plus, even if the engine was culling on per entity basis, I wouldn't group all ladder segment on the level into one big entity. I would group it per ladder. This way if I had 5 ladders made of 1000 pieces total, I'd have 5 muti-model func_statics, instead of 1 multi-model func_static.

 

If you're assembling 200-piece ladders in the editor I'd say you're using the wrong tool for the job. Radiant and its siblings are designed for high-level alignment of world geometry and meshes, not for detailed precision modelling. Even if better support for func_static grouping were implemented the editor still wouldn't possess nearly enough functionality to replace Blender, Lightwave or Maya for this purpose.

Link to comment
Share on other sites

SEED is TDM-only feature. DR is used for many other projects using idTech 4 or derivatives. It would be much easier to add support to Doom 3 for multi-model func_static than port SEED. Plus SEED doesn't solve the issue arising from modular design of the levels similar to UE3/4.

 

But then I'm not sure why you ask about this on the TDM forum. We only have the ability to work on TDM, or on DR - but both do not solve problems with Doom 3 (things generally are not backported from TDM, as you said).

"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

If you're assembling 200-piece ladders in the editor I'd say you're using the wrong tool for the job. Radiant and its siblings are designed for high-level alignment of world geometry and meshes, not for detailed precision modelling. Even if better support for func_static grouping were implemented the editor still wouldn't possess nearly enough functionality to replace Blender, Lightwave or Maya for this purpose.

 

I assume you are familiar how UE levels are made. While idtech 4 has no occlusion culling, we can still block out level using caulk brushes, and then simply add decorative architectural models on top of that. Models are made on the grid. Some models of course aren't made on the grid, but those don't have to be precisely aligned anyway.

 

So UE3/4-like efficient workflow (and kit-bashing) is possible to a degree, but management of many entities is cumbersome and entity count is an issue. Entity management can be solved by something similar to func_group (it might even work out out-of-the-box in DR, I haven't tried it yet) if entity limit issue is resolved, or with multi-model func_static if not.

 

Making levels in 3D app is a royal pita, and since engine can't cull continuous surface, nor it can use models, even inlined ones, as vis blocker, making levels in 3D app is a no-go for idtech 4. It's been already proven that there is no faster workflow than using CSG geometry (bushes) + models.

Link to comment
Share on other sites

But then I'm not sure why you ask about this on the TDM forum. We only have the ability to work on TDM, or on DR - but both do not solve problems with Doom 3 (things generally are not backported from TDM, as you said).

 

Because DR is not TDM and I am asking in DR section of the forums. If DR was TDM only I wouldn't really be here (nor anyone would use it for any project, or test it for that matter).

Edited by motorsep
Link to comment
Share on other sites

Because DR is not TDM and I am asking in DR section of the forums. If DR was TDM only I wouldn't really be here (nor anyone would use it for any project, or test it for that matter).

 

Ah, my bad, I didn't notice the section and misunderstood the exact question.

Edited by Tels

"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

idTech 4 performs per-surface culling, not per entity
The early, cheap, culling is full entity, except for the models that dmap generates from worldspawn. Individual light/surface interactions can be culled later. We use the trick a lot: put a bit of an fs in your current visleaf and you'll see all of it. Useful for making a distant tower that's part of your map but visible from anywhere. Merging models into a bigger fs would be very handy combined with that trick.
Link to comment
Share on other sites

The early, cheap, culling is full entity, except for the models that dmap generates from worldspawn. Individual light/surface interactions can be culled later. We use the trick a lot: put a bit of an fs in your current visleaf and you'll see all of it. Useful for making a distant tower that's part of your map but visible from anywhere. Merging models into a bigger fs would be very handy combined with that trick.

 

It's not the best way. You can have a big a** model comprised from several surfaces and with entity culling it will render whole, even if you see a small tip of it. With per-surface culling, only surface(s) that is visible will be rendered.

Link to comment
Share on other sites

Models are made on the grid. Some models of course aren't made on the grid, but those don't have to be precisely aligned anyway.

 

Hang on, if we're talking about func_statics made out of brushes and patches then this isn't a discussion about "models" at all. I thought you were asking for the ability to have a func_static containing several different ASE or LWO models exported from a 3D application. As far as I know DR already has support for func_statics that are made out of as many brushes and patches as you care to create.

 

Is your request simply for better editor manipulation of func_statics containing brushes and patches, i.e. manipulating them as a fixed group rather than as individual primitives? Or is it just the "combine" function that is missing once you have grouped brushes into two or more existing func_statics?

Link to comment
Share on other sites

Hang on, if we're talking about func_statics made out of brushes and patches then this isn't a discussion about "models" at all. I thought you were asking for the ability to have a func_static containing several different ASE or LWO models exported from a 3D application. As far as I know DR already has support for func_statics that are made out of as many brushes and patches as you care to create.

 

Right, I was talking about func_statics with LWO/ASE models. Multiple brushes can be already combined into a func_static.

 

Is your request simply for better editor manipulation of func_statics containing brushes and patches, i.e. manipulating them as a fixed group rather than as individual primitives? Or is it just the "combine" function that is missing once you have grouped brushes into two or more existing func_statics?

 

At this point (until we sort out whether multi-model func_static is feasible and better than inlining or client-side entities) I simply want to select several func_statics and "group" them, so that I can select entire group, instead of selecting them one by one. As I mentioned earlier, Quake 3 Radiant / GTKRadiant (not sure about DOOMEdit) had func_group that did just that. Map compiler would just ignore it. I don't know how it would work in idTech 4 / DR. Ideally it should be DR's feature, like layers.

 

Here is what I found in the code:

 

// move the primitives of any func_group entities to the worldspawn
if ( entities[0]->epairs.GetBool( "moveFuncGroups" ) ) {
 for ( i = 1; i < entities.Num(); i++ ) {
	 mapEnt = entities[i];
	 if ( idStr::Icmp( mapEnt->epairs.GetString( "classname" ), "func_group" ) == 0 ) {
			 entities[0]->primitives.Append( mapEnt->primitives );
			 mapEnt->primitives.Clear();
	 }
  }
}

 

Apparently it should work out of the box: http://forums.thedarkmod.com/topic/6096-wow-comments-on-anything/page__p__117416#entry117416

Edited by motorsep
Link to comment
Share on other sites

I am aware of that, stumpy. But for organizational purposes I need to group entities (or entities and brushes) together in DR. Not turn brushes into func statics.

 

I looked into the code last night and it doesn't look too complex to add multi-model support for func_statics. I think being able to group entities with entities and brushes using func_group, and using inlined func_statics is a better way of doing things. Just need to enable creating of func_group entity when entities are selected in DR (currently Create Entity is grayed out when entities are selected).

 

EDIT:

 

Here is what I am planning on doing - I'll make a test case for func_group using entities and mix of entities and brushes (manually editing .map file). If that works with dmap/engine, then it would be a good idea to either add shortcut for func_group (same as Convert to func_static) or allow creating a func_group entity when several entities/brushes selected.

 

Sounds like a plan ?

 

EDIT2:

 

func_group works in the engine, but incorrectly - after engine reverts brushes to the worldspawn on dmap compile, they end up at the center of the map. I guess func_group gets moved, then reverted. DR can't load func_group with entities. I don't think engine supports func_group with entities either.

Edited by motorsep
Link to comment
Share on other sites

I understand the need for grouping, but that's not something that is implemented over a weekend - it's not just my personal unwillingness to code it, it's quite a deal of work.

 

Right. My thinking was that engine already supports func_group with entities. But not only it doesn't, it's broken even for brushes. So that's out of the door.

 

Adding multi-model func_static seems like the best idea, but I don't really know what's involved getting it done right (merging surfaces with the same materials within func_static into one batch).

 

So to save headaches and time, I think utilizing layers and inlining (that is also broken, but trivial to fix) is the workflow of the moment :) (unless there is a limit on number if layers that can not be easily expanded).

Link to comment
Share on other sites

Some initial thoughts on how editor-only grouping in DR might be implemented (for future reference, or in case some enterprising open-source contributor feels like tackling it).

  1. Define a Group object identified by a UUID that contains a list/set of all entities contained within the group.
  2. A suitable manager object in DR is responsible for maintaining the list of groups. Possibly the SelectionSystem since this is involved with mouse dragging and selections.
  3. When a set of entities is combined into a group, a new Group object is created with a new UUID, and this UUID is set as the value of an editor-only property on each entity (e.g. editor_entityGroup). The Group object is then populated with pointers to all of its component entities.
  4. At (or shortly after) map loading, DR walks the entity tree creating Groups on demand based on the values of the editor_entityGroup key on each entity, and adding entities to the resulting Group object as necessary. This ensures that grouping can be saved and restored with the map file.
  5. Whenever a transformation is performed on an entity with an editor_entityGroup property, the corresponding Group object is looked up and the same transformation applied to all other entities within the group. However, this is only trivial for translations. Rotation and scaling is considerably harder because this needs to be based around the center of the group, not the center of each independent object.

Limitation: this will only allow entities to be grouped. It will not be possible to add worldspawn brushes or patches into groups unless they are turned into func_statics first.

 

Further work: simple grouping and ungrouping is probably OK to start with, but people will want the ability to "enter" groups to make local changes without breaking the group structure. There will probably also be a need for some GUI to list and manage groups, maybe give them names etc (although perhaps this is overlapping too much with the Layers functionality).

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

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • 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
×
×
  • Create New...