Tels
-
Posts
14984 -
Joined
-
Last visited
-
Days Won
23
Posts posted by Tels
-
-
In vanilla Doom 3, each model gets it's own VBO. In BFG, there is a global VBO for all geometry. Mh made a revised vanilla branch where this
improved behavior is present. There still may be other inefficiencies with model tracking that are surmounted by combining models though:
See tracker: 3234
Well, I'll leave that to the experts then. Hopefully someone can then rip out the unneeded ModelManager once all the VBO optimizations have been brought in.
-
Is the figure shown on the console before or after def_attached entities get spawned? If before, it won't help much.
I meant it should be added, not that it is already implemented
Outputting one line with some statistics after map load like:
Map NAME loaded: 123 entities, 12 models, 6 lights, 3 AI, 5 triggers
That wouldn't hurt (its a simple counting over all entities once) and there would no need to remember a command etc.
About the spawn: I don't know offhand wether the combo entities are spawned right during mapload, or in or after frame 1. Good question.
-
That's precisely what a VBO is: a cache of vertex data that can be stored on the graphics card and rendered as many times as necessary. You still have to call a function to instruct the GPU to render the VBO geometry, but it's much faster than submitting all of the vertex data again. Any modern game will already be doing this with static meshes, because submitting the vertex data anew on each frame would be horribly inefficient.
(In fact with modern OpenGL versions you are required to submit your geometry in VBOs, even if you only render it once. The old immediate-mode function calls are all deprecated).
I wonder why TDM is then still much slower to render 100 models than to render one "100 models merged into one" model? Or is the slowdown only happen for old hardware like mine?
-
Is there a way to get an entity count in game from the console? Hopefully so. I'll take a look if no one knows. And if there isn't, adding the console command to svn would be a quick job.
I think just outputting the number after the map has loaded to the console would be enough.
If it is >8192, the game will crash, anyway, and if less, the mapper can simply load the map once to see the number.
(The amount that is in the map shown by DR doesn't need to be printed - afterall, DR shows it directly. But the amount after loading can vary plus (torches, AI) and minus (SEED and LOD and other things that remove entities directly before spawn like the "random_spawn").
-
Well, that's the funny thing about open source and modding. Sometimes folks are more motivated to work on stuff that's "broken beyond
belief" or if the end-result is deemed "impossible" rather than improving or fixing something that's functional.
EG; This may attract a few new developer faces.
It is because of this quirk in social behavior I am almost tempted to suggest we release some of the broken rendering stuff in SVN just to see
if some coder get's frustrated enough to join the project to "fix it".
Yeah, but in all likeliness the result is "oh, yeah, it is actually impossible, and I spent already more than 10 minutes on it, boooring and school starts tomorrow again, so I'm outta, boys, good luck". Countless mod projects never got past the first experiments. I wish it was different, but...
I'd rather take some fixes for some small, but annoying problems we can make available to all users, than some half-hearted attempts at running against the wall and do the "impossible". Like, we don't have support for characters like ã in our fonts - or we still don't have EAL, but heh, running TDM on Android, lets work on that... (It's not the "running on android" big I'm objecting to, but the "lets use a vanilla D3 engine to do so", which doesn't really help anyone).
-
A 4-7Fps increase looks like a general driver improvement only, the equivelent nVidia card (GTX660) would be flat out @60fps at your highest setting. I have emailed my contact to see what version the driver team will include The Darkmod fix in.
It is actually a decrease (47 =>43), but at much higher settings. So this test result is useless, one would need to see the difference at the same resolution and AA setting to see what the difference is.
-
I believe that "listCollisionModels" is the console command for that.
There's also "CollisionModelInfo" but I think that just shows you details about a collision model you are looking at.
The CM limit could be raised, if there is need, I think. (It depends if we have another bit free).
Basically, every moveable has a CM. So you can't have more than 4090 or so moveables (player spawned arrows, absence markers and so on would also have a CM).
As for the other limits, the entity limit on the webpage says not more than 6000 or 7000, but you have 7700 so that would be the limit that can be reached (you loaded the map with TDM, right)? We should adjust the wiki. However, don't go much higher. During runtime, entities will be spawned, Like the combo entities, arrows and so on. If the game runs out of entity slots, it will crash. That could be quite well during the mission.
I think you can still use seed_combine and seed_watch_brethren on models even if you don't use the random portion, Tels has done this to Johaness Burrock's test map
in the SVN repo. You may wanna ping Tels to get pointers.
http://wiki.thedarkm...tching_entities
See?, no random at all.
Yes, exactly. I guess this part should have had a different name, as people seem always to confuse these two
"Watching entities" with SEED also has the advantage that the entities are removed during the runtime, meaning you have more entity slots free.
-
Hmm... I recall that even pre 3.x OpenGL had instancing though some of that was done in the CPU.
These sites seem to provide the older method:
This would actually be what the ModelGenerator should use - upload the model once, plus the instance data (position, scale, rotation, color) and then let the vertex program render all the instances in one go.
That would save the combining of models, plus the finishsurfaces steps and so on.
I think that even the renderer should do this automatically (or an object in front of the renderrer). There isn't a reason why 100 movable apples in a room shouldn't be automatically batched without mapper intervention.
-
It'd be a case of looking whether the most-used particle materials are (a) two-sided, and (b ) used ONLY in view-aligned or aimed particles. Those would be the candidates for one-sidedness. Thinking about it, I'm not sure whether there'd be any gain though. Ordinary surfaces like glass apparently generate a wasted draw call when they're two-sided, but the multiple quads of particles are already batched into one draw and have openGL set to cull backfaces, so there might be no gain. Probably best not to spend time on it. An extra draw call per particle stage -- even if it happens -- is a smaller fish to fry than some of the other stuff we've been discussing.
That may be true, if isn't the engine generating needlessly the backfaces for particle, then uploading them, only for the GPU to cull them again?
I'l see if I can have a quiet evening and a look, but no promises, the next weeks are quite packed already.
Vertex programs can't create or destroy vertices, they can only move them and tweak their attributes. So to generate a particle effect using the vertex shader only I *think* you'd have to upload a big pile of vertices for the particle to the GPU at map start, then use the vertex program to move them and set the color (=alpha) each frame to generate the desired effect. Stationary vegetation is a bit different. No need to move the verts so no need to fiddle with it as long as you can rig it so the lot get drawn in a single pass. To create new verts in the GPU I think you need to use a fragment geometry program, and I think we won't get that capability unless we upgrade our openGL and are using GLSL instead of ARB. I'd be interested to hear what revelator and nbhor1more have to say on this as I started studying rendering only 2 months ago and I'm only repeating what I remember from the stuff I've read. There might be tricks and techniques out there to do it differently.
Hm, yeah "creating" verts would be for the tesselation stuff, but this isn't actually nec. if you have just 100 times the same plant.
Couldn't one upload the data once, then use the vertex shader to draw it 100 times by calling the same shader 100 times with different parameters? Or is this "one call per model" and what is so expensive? (I freely admit I only have hazy ideas about the entire 3D stuff and over the years I've actually forgotten a few things I used to know
Edit: "generate 100 plants as one surface, upload it once and render it in one drawcall" is EXACTLY what the ModelGenerator from SEED does - it is just that it has a few inefficiencies:
- If there are models with shadows, it combines X models, then calls FinishSurfaces() togenerate the shadow verts. That is VERY slow. However, if you have 100 shadow casting plants, you should be able to generate the shadow once and then replicate it 100 times just like the geometry. This was never fixed after the engine did ggo open source. This can cause a lot of stutter.
- Even without shadow casting surfaces there can be stutters if you have a huge amount of models with LOD stages and the generator needs to regenerate a combined model because one LOD stage changed somewhere. Stutters again.
- It is a manual method (add SEED entity, link children to it in DR, maybe 10 minutes work). However, mappers rather optimize their map for 10 hours than 1 hour on how to learn how to use SEED ... So almost nobody uses it. The engine should do these things dynamically and in the background ("render frame, see that X models of type Y are on screen, batch them together and draw them in one go").
Would be cool to see this finally getting used (like a lot of my work that just never got really used).
- If there are models with shadows, it combines X models, then calls FinishSurfaces() togenerate the shadow verts. That is VERY slow. However, if you have 100 shadow casting plants, you should be able to generate the shadow once and then replicate it 100 times just like the geometry. This was never fixed after the engine did ggo open source. This can cause a lot of stutter.
-
Hehe, a hint perhaps. I'd not put it stronger than that. In the extremely unlikely event you have nothing better to do
I'd need a more clear description of what actually todo – must admit I only skimmed that thread and there are so many things going on at the same time here
Also, I don't have SVN access. So far I'm only trying to be helpful with my limited experiences of the code From what I've seen so far TDM barely uses the vertex shader, except when drawing shadows. So we have an opportunity here to fill that vacuum and get cool stuff for free: rain that doesn't slow maps perhaps, or a crowd of AI on screen instead of the current limit of 6.
Yeah, or 10000 plants instead of only 100
I'm still not sure why it can't be possible to send the data for one model to the GPU, then have a vertex shader "multiply" it and render it multiple times - that can't be that hard as that would be THE #1 thing game engines try to do for vegetation, right? -
That looks like it's been carved from the cliff rather than built from stone. Very cool.
100 people, a heap of chisels, and a LOT of time
-
Holy hell! That's pretty awesome to even see it load that far. lol
And sitll quite useless, because how on earth should TDM 2.02 standalone still run under D3? I'm amazed it doesn't crash outright. Guess for the next version a check should be included to stop TDM DLL to load under D3, as it isn't going to work anyway,and only gives people false hopes....
-
Hmm i might misunderstand a few things so let me ask you have a special function -> SEED that batches things up into one large array ? or do i miss something.
Yes. SEED builds a virtual model (in memory only) by copying the data from one model multiple times together. It can even update the virtual model at run time (although this is very slow). The integration of that function into the renderer is very poor, because it was written before we had the full source code.
The source code is in game/ModelGenerator.cpp line 500 and onwards.
-
You'll find the usage data on my tracker for soft particles: I made a list of all materials used in particles, plus which particles they are in and how often they are used in entity defs or directly in maps. Linux-friendly Open Office format too
Was that a request that I do something with that?
That's how the particle system works too. One discontinuous surface for the multitude of separate billboards. That's why I'm not afraid of using the soft particle shader with perf-heavy performance particles like rain. It's only one draw, and the fragment shader executes per-pixel so tiny particles will cost proportionately less than big ones. The perf hit probably comes from calculating and sending to the gpu all the thousands of tiny verts for the raindrops each frame. Sodft particles won't add any extra work to that process. Not that I'm planning to propose using it for rain -- rain isn't view-aligned so won't get meddled with under the plan I'm drawing up now.
Speaking of particles - IIRC things like smoke remove all their planes (verts and all) and rebuild them every frame, via the CPU. Shouldn't that be done on the GPU instead?
To the batching:
id4 (or at least TDM) batches per surface - however, not every surface in a model is a surface in the game. IIRC the engine tries to combine multiple surfaces from a model if they have the same shader - I guess that is so that if you have:
- surface A - rust
- surface B - metal
and use a skin and change B to rust, you end up with only one surface after loading[0], and not two surfaces with the same shader. However, it might be that this doesn't always work, like for some modelformats only (ASE vs. LOW?) and depends on the skin at load time(see [0] again). Or maybe it's buggy, or not really implemented (and I remember wrong).
Plus, at rendering time, I'm not sure what the renderer does. Does it render both surfaces A and B together, or one after the other?
So it is perfectly possible that you have a model that consists of more than one surface with the same shader on it.
0: There is that long-standing bug that a skin is applied at model load time, and if you later reskin the model, you can't change a few properties, like the sidedness. Once onesided, or two-sided, the surface stays that way, even if the new skin says otherwise. The reason is that the duplication (or not) happened already on load. But I digres
- surface A - rust
-
He's off his meds again, isn't he?
-
Nope, you'd need v1.07. v1.08 was merged with the GPL source but was not standalone due to assets. v1.07 is the last TDM version that was truly a
Doom 3 mod. Even then, we were using hooks to get low-level access to the executable... DIII4a's code structure is significantly different, those hooks
might not work.
What he said
I'm not sure what will be accomplished even with getting v1.07 to run. Even if it starts, the machine you are using only has 64 MByte VRAM, which might not run be able to run a lot of FMs.
Plus, no user would want to use any TDM less than 2.02 - and we definitely can't go back from standalone to D3 mod.
-
Well i can test it for you, because I got doom 3 running on my tablet!
Lets see if i can run TDM (earlier version) as a mod.
Not from 2.0 (standalone) onwards, you definitely need both the TDM engine and the TDM game dll to work together.
I'm not sure with v1.08, it might still work as a mod on the older D3 engine.
-
I tested TDM 2.02 with DIII4A on my tablet nexus 7 (first edition).
I only get the "darkmod old watch"-screen displaying the error #str_04350 and then the app closes.
And get the following log:
I'm not sure what Dll4A is, but if this isn't the real TDM engine (which is hinted by the "DOOM" string in your log), then this will not work. The TDM engine does a lot of things differently than the vanilla (or modded) D3 engine, so loading TDM maps or even the menu with D3 will not work at all.
-
Oh god i just talked to mh and its pretty much pointless as vanilla allready batches pretty much everything allready [snip]
No, it doesnt :-) http://wiki.thedarkm...tching_entities
Especially in the case of "non-lit wood in the night" the batching could be improved considerable. Even the SEED method could be improved, as it currently builds the new geometry in an awkward way on the CPU.
Edit: Here is the old thread: http://forums.thedar...243#entry243243
Note that SEED (formerly known as LODE) does two things:
- random generation of entities/models and distance-based culling/re-instating
- combining rendermodels of multiple func_statics or models into one model (optional: with multiple clipmodels)
The old thread often talks about 1 but occasional 2 is also mentioned.
Sorry if I can't pick out the relevant posts right now
A few interesting posts with screenshots:
- http://forums.thedar...post__p__243972
- views:4 draws:235 tris:12782603 (shdw:306) (vbo:0) image: 49.9 MB
http://forums.thedar...post__p__244362 - http://forums.thedar...post__p__246658
- http://forums.thedar...post__p__247177
- real world test with NHAT: http://forums.thedar...post__p__247907
- multi particle emitters http://forums.thedarkmod.com/topic/12107-announcement-seed-system/page__view__findpost__p__248646
Please note that all the above posts are from before we had the full source code - some info might be outdated and we probably could fix quite a few problems now much more easily.
- random generation of entities/models and distance-based culling/re-instating
-
It's just a keyword that wants removing from the material file -- twoSided. We'd have to check the material wasn't used in any genuine 2-sided scenarios though. We have 300-odd particle definitions sharing 97 materials, and the twoSided keyword goes in the material decl. We could safely remove it for any material that's used only in view-oriented particles.
That's what I meant
Please keep in mind that the definitions of our matierals&entities aso where often simply copy&pasted from people who don't understand them, so we have a lot of small mistakes and mess there.Edit: I guess fixing the most-often used materials first would give us the biggest win.
I looked up the instancing function. There's a specific draw command for it glDrawElementsInstanced to complement the glDrawElements that our code uses. You need a vertex program as expected, and you can pass it a load of data for individual instances in a "Uniform Buffer Object", or for repetitive stuff like a field of grass, you can make it repeat with variations on the gpu without needing to pass data. It would be good for vegetation or a forest but I'm not sure we'd notice any benefit for existing maps. You apparently need 100s of instances of something on screen before it becomes the must-have choice. Your SEED method is probably as good as instancing for the kind of things we've seen in maps (so far).
The probem with SEED is: It is manual and virtually nobody uses it.
Take f.i. the new version of the Alberic map. It has a ton of vegetation models to the extend that the entire DR view is blue from top. But it doesn't use SEED, so the engine draw dozens of bushes, grass mushrooms and so on model-by-model.
SEED can help with that, but the mapper has to use it. It would be much better if the engine knows "heh there are 20 bushes right next to each other, lets batch them together". Basically, it's what SEED does, but auto.
SEED currently in this cases combines all the model geometries so that for each surface, you end up with one surface (non-continous) per material.
-
Upgrading got rid of the black boxes and the floating nails, but I still cannot get the "Figure Out What is Going On objective and the mission still will not complete.
If you have started the mission with TDM v2.01, and are now at 2.02 - you will need to restart and replay the mission - savegames are usually not compatible between TDM releases. Sorry
-
1
-
-
Get an early unstable RPM package (with the source) from my site.
Bugs:
After installation all the files have executable permissions.
shortcuts doesnt work and have no icons.
TODO: must copy the .desktop files to the right folders.
You are missing the "the" on the name
It is "The Dark Mod" (TDM) NOT "dark mod". Likewise, it is "thedarkmod.com", NOT darkmod.com
-
1
-
-
Would that be as simple as passing the model once, and applying a different transformation for each draw in the vertex shader? Does that still take multiple draw calls, or is there a way to request the multiple instances in a single call? I guess you'd have to pass all the different origins, orientations, and scales too, an array of projection matrices. And for animated models like AI, a list of joint positions for each draw too.
For static meshes (leaving aside animated things for now), I guess passing along the transformation (offset + rotation) plus a color value (so you can randomly re-color the vegetation and add variety this way) would probably be enough. I'm not sure if a vertex shader can re-draw the same thing twice (with tesselation, it might generate new triangles?) but you could call the same shader multiple times. But I'm not an expert.
https://en.wikipedia...etry_instancing
Apparently it is in OpenGL, too:
https://www.opengl.org/registry/specs/EXT/draw_instanced.txt
Not tested yet, but I think we might have a problem with our particle materials if we co-opt GL_CULL to do the work. They don't cast shadows but they are two-sided, some correctly (stationary, non-view-aligned particles like the electrical discharge on generators), and many incorrectly (a lot of view-aligned particles are two-sided unnecessarily. Looks like a mistake got into a template). We can still try the technique, but we might have to put the toggle elsewhere in the code.
Could the two-sided particles get fixed? Is this a simple keyword in their materials ("onesided") that needs to be added? That might gain us a cheap bit of performance.
-
Btw might be worth it looking at doing batch proccesing, vanilla still uses the old opengl 1.1 vertex arrays but i played with replacing them with glVertexAttribPointer and to some extent it was working. My biggest problem was getting the right attribs in some places.
Model instancing (is this the same you are talking abut) would also be a benefit for vegetation. SEED does a poor job (it was written before we had the source) in drwing thousands of models by combing them all into one giant model and then draws it. That saves draw calls, but still could be done much better by sending the model to the graphic cardonce and let the card draw it multiple times.
trying to run TDM on Android
in TDM Tech Support
Posted · Edited by Tels
As I said, the D3 vanilla engine lacks many things that the TDM engine added - like extended GUI commands, extended scripting events, extended animation frame commands, CVARs (we dropped a few, added others) and so on and on and on and on.
It's quite a fruitless endavour to track this stuff, because you would technically need to merge most (if not almost all) changes from the TDM engine back to the vanilla engine to run a TDM map under D3.
There is a reason we are not using the D3 engine anymore, but a modified variant of it.
Edit: And in case I didn't spell it out properly yet: If you load a TDM map under the D3 engine, the map is very likely to not work, or outright crash, because of missing features in the engine. And no, getting it to "almost run" doesn't help, because what good is it if you can run TDM maps on Android, but only one without scripts and where the AI does not work?