motorsep

A better question is if TDM will ever switch the engine. It that would be on the roadmap, it would make sense to go all out about choosing a fork, features, etc. As it seems to stand now, no one is going to switch anywhere, unless someone takes TDM engine and modify that. That is not correct. BFG engine takes Cg shader, and generates GLSL/HLSL/CGB out of it (PC/XB360/PS3). You could technically write all of those shaders straight out, skipping Cg. But the engine was designed to make it easier to author shaders at once for all platforms (although CGB part is not in the GPL code base). The parser maybe makes up a large portion of the code (it's not even rendering code technically speaking), but rendering code is larger because it's threaded, and because it comes from RAGE - different rendering architecture when comparing to Doom 3. There are 2 parts that are necessary to improve in order to gain performance - skinning and shadows. Going with GPU skinning and shadow mapping will get you the max performance. That's why going with BFG is a much better option in a long run, than patching up idTech 4 making mess out of it. However, that's a very nature of unpaid FOSS development

I have been brainstorming better ways to setup lighting on the level, and remembered the method used in Quake 4 map Strombine. With that method, one would have to take screenshots on XYZ window in order to paint light images. Some people work on laptops, some have regular HD screens, and taking top down screenshot of a big level will result is loss of details. Would it be possible to add internal screen shot taking capacity (a la Blender) with ability to set virtual resolution that is larger than the screen resolution?

http://forums.thedar...post__p__332343 Are you talking about this? ^^^ That looks like using influence in Doom 3, which in turn uses FX Manager.

ARB support will be dropped earlier or later, so you won't be able to run your game one day with newer drivers. Also, GPU skinning is not possible with ARB.

You know how there are doubleVision, enviro suit, etc. effects in Doom 3 (and I am sure TDM uses something similar). I am wondering if we make a custom shader (night vision for example), how would I apply that to the player's view without using that horrible FX Manager ? (basically afaik it would be better to do everything in the shader, and maybe feed parameters into it for deforms/shift/etc.) Thanks.

Did you export ASE from DR or Blender ?

I see. Well, func_group will still be there for grouping worldspawn brushes. And the new method would be for entities (hopefully lights would be included too).

You can already group brushes using func_group in DR. I haven't tried it yet in DR, but I recall I was able to select individual brushes inside func_group and move them around, then move entire func_group as needed, in GTK/NetRadiant for Quake 3.

I think 2,147,483,647 layers is plenty of layers Or am I reading it wrong?

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

Autodesk offers trial version as always, I think. So to make it work with 64bit, you need for MayaImport to be ported to x64 ?

Is there a limit for number of layers in DR ? If so, is there a way to increase it ?

I am giving up on this for now. Will use layers / inlined models.

Is there a way to get Maya 2015 full and LT 32/64bit compatible MayaImport DLL ?

Can you master github repo be compiled on Linux ? Or is it Windows only currently ?

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.

Oook, func_group is there, but doesn't work with anything but brushes, which makes no sense :/

Right, I was talking about func_statics with LWO/ASE models. Multiple brushes can be already combined into a func_static. 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

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.

What we will do most likely is that we are gonna bump entity limit and fix inlining first and see if that would be enough. Either way having at least something like func_group in DR would be nice for organizational and scene management purposes.

Another thing to note that if engine can scale models in run time, then DR should probably allow scaling of the models too.

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

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.

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

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.