motorsep

Why not just crank up entity limit to a million ?

I would think for indies using idTech 4 / BFG engine, having ability to shove in more entities on the level without increasing upper limit would be a good thing I also doubt that average indie will manage to make scenes with millions of world clutter objects. In a long run proper instancing of static and dynamic (skeletal) models would be a good thing. However when I spoke to one of the renderer programmers I hired to work on shadow mapping, I was told that it would be a major rewrite of the portions of the current renderer. And that still doesn't solve the issue with entity limit, unless we can simply increase it to a million and have no negative effect (someone mentioned that increasing size of that fixed array decreases size of the other two dynamic arrays, which will make the engine run out of dynamic entity slots and crash during the gameplay) And when it comes to major rewrites of idTech 4 / BFG, it makes me think going with UE4 / Unity would be a smarter decision (unless introducing instancing isn't that big of a deal).

Got some info from Brian Harris. He said that discrete surfaces will never be combined. I wonder if there is some exception for IsDiscrete in the render code too, besides dmap code. If so, then I'd have to naturally add another check into that if() in dmap so that while surfaces are separate in .proc, they still get merged on render time.

Hmm. Makes sense to not let them spawn on map load. I wonder if entities can be removed before entity count kicks in.

How is it a step backward ? You'd really only want to use inlining for stuff you never need to reference to, like rocks, grass, foliage, architecture. Even though the surfaces aren't merged in .proc, they will be batched in runtime, just like the models are. Dmap just saves one step by pre-merging surfaces in .proc. Now that I think about it more, there is one inconvenience - gotta recompile map every time you move inlined entities. Might as well just not inline them until final build :/ The way we fixed inlining was not preventing entity from spawning. The fix was removing inlined entity after spawning, and retaining collision model instead of discarding it.

Well, you can still see inlined entities as regular entities in DR.

Map bloat isn't a problem. That's how maps are in other engines. Older engines were even worse, having lightmaps embedded and models inlined. Some levels in Steel Storm are 80+Mb and that doesn't have negative effect. So the only issue I see is longer compile times (if you get a rid of shadow issues, which I haven't experienced yet). Although I would prefer having entities that don't count as entities

Thanks. I think adding 'discrete' flag should solve it. I'll test it and if it doesn't work I'll add another condition to check for lod surfaces and not merge them. But I have a gut feeling 'discrete' is all I need

I recall noOptimize for dmap is to not cut surfaces on the light boundaries. I'll try "discreet" flag in the material and report back.

Is it possible to have entities, that don't count as entities? I am sure that modern engines have a way to have all the foliage and world clutter without embedding entities into the map.

So we implemented LOD last night. It works, but there is an issue with map's geometry (and inlined entities). Apparently dmap merges surfaces with identical materials into one large surfaces (and that could cause longer map compiling times too). For LOD to work properly, each surface has to be written as separate surface. Is it possible to make dmap write each surface as separte one, regardless if materials are identical ? Where in the code dmap does the sorting and merging ? Thanks.

Isn't it something I recently inquired about in a separate thread?

Not sure about TDM engine, but having models in .proc files reduced memory usage and increases map loading time for us. Map compiling slowed down a bit. Although I haven't tested it fully with that many entities. Can you upload your test map somewhere (with all appropriate assets, so I could just plug it in and run it) ?

I get that, but I don't think you guys understand what I mean. I am talking about real-time, interacting with UI and changing parameters on several selected entities. Not applying one parameter at a given time without seeing a feedback.

That's the most user-unfriendly way :/ I am talking about user-friendly way, where you see the common spawnargs displayed in the entity inspector and you normally, via GUI, tweak them, as if you would have done for single entity.

I am wondering about adjusting existing ones, not adding a new one.

I wonder if it would be hard to add such feature, where you could select several lights, or other entities, and adjust their common spawn arg at once for all? For example, if I select 100 lights, and I want to adjust color on all of them, I would just change color and it would affect all selected lights. Currently I recall only last selected would be changed (or first selected).

Well, if you can just look into game code, you can see that BFG's codebase is D3+ROE. Maybe minor differences. Porting game code of TDM to BFG is easier than trying to make modern rendering engine from TDM engine.

@revelator: I think (and that's just a thought) it would be better to begin porting game code to Doom 3 BFG code base. This way you could figure out all the incompatibilities and when I release my engine, you could just merge the game code of TDM and that would solve all the issues at once

Thanks. I tried it several times. Didn't have much luck. A lot of folks who contacted me either never modded anything, or worked with Unity and when they tried working with idTech 4, they just couldn't wrap their head around it. But I guess I can try again

Internet is massive ... no, supermassive. So simply answering "on the Internet" doesn't help, since that's where people search for stuff and people. So it is implied that I am looking on the Internet already. So would that help to relief brain strain if I ask "what places on the Internet do C++ programmers, who relate to game dev in one way or another, hang out and share experience / ideas, which also happen to have 'Offering Help' boards" ?

Xonotic uses IQM almost exclusively. MD5 is fine for Doom 3 engines, as long as animation system stays in place. IQM has robust Blender exporter and I believe it can already convert FBX to IQM. So there is no need to struggle searching for working exporters for several 3D apps. It also supports vertex color. One disadvantage of MD5 and existing animation system is that bones inside MD5 have absolute coordinates. Meaning you can share animations with models that have different skeletons (as far as locations of the bones). So let's say you have 2 characters with exactly the same bones, except that one has longer spine and wider shoulders. With IQM, you can export 2 models, and 1 set of animations. With MD5, you have to have 2 models and 2 sets of animations. It's not totally bad, but just pointing the disadvantage (which I experienced first hand last week). Note I am not advocating to replace anything in TDM

Why would anyone want MD3 models?! It's almost impossible to author the format nowadays. IQM model format would be interesting to add, or OpenGEX.

No, not yet. It's also Doom 3 BFG engine based.

That's obvious