What are you working on?

[qbism]

The epic maps and mods created in the last few years are more interesting to me than running the original Q1. But I still prefer the old pixellated look. That's the spark to support bigmaps, which started AFAIK with BJP's winquake in 2007. I'm able to move quickly on Super8 dev because most features derive from previously existing engines.

[leileilol]

My problem with Darkplaces atm is performance - FTE and RMQE run circles around it.

what

[Supa]

In between one spate of Life Issues and the next I've been working on a little something alongside RMQ - some of you know what this is about, everyone else should be able to guess. :)

[Ace12GA]

My problem with Darkplaces atm is performance - FTE and RMQE run circles around it.

what

So what is with the apparent hate on for DP? I think its great to work with. DP supports more modern model formats, is easy to work with, runs well on Windows and Linux... Lots of nice QC extensions... I'm not seeing the downside.

[mh]

There's no real hate on DP. Just that for heavy content, it is very much on the slow side. Much of that is down to overburdening the CPU with things that should be moved to the GPU on more modern hardware - on start.bsp DP tops out at maybe 80% GPU usage for me, veering wildly between that and a low of 50%, whereas DirectQ hits a steady 99% and stays there. It also has it's own slightly idiosyncratic way of doing some things, and occasionally breaks compatibility with standard id Quake. But for what it does, it's quite alright. Performance is nowhere near what it should be (it could go 4 times or more faster in certain situations) but quite alright.

[Spike]

its not the engine per se, but the design decisions that resulted in various key features that allow other engine modders to gloat about so easily.

mh, While I've no doubt that directq reaches 99% gpu usage, I feel I must point out that you could push the entire map to the gpu in a single vbo without any culling and still get 99% gpu usage, yet get a third of the framerate. I'm kinda distrurbed that DP is actually reaching even 80%, I can only assume that's the sky renering.

Ace12GA, The ideal of optimising is not getting 10 million fps, but optimising the cases that really need to run fast. In DP's case, this is rtlights. For every other engine, demos like bigass1/overkill etc are a higher priority - worst case scenareos that will actually happen when playing competitively.
For the people who's machines are simply not powerful enough to run rtlights, and are still underpowered for other things too (say, cheap intel gpus or laptops), any performance from DP just isn't there - it really isn't optimsed for it. People 'forced' to use DP just to run specific mods when some other engine would get twice the framerate are understandably going to be resentful of that.
DP just isn't competitive against other clients. This is most comic with DP's QuakeWorld protocol support - a server where you have people playing with _stable_ 320+ fps, and a DP client joins with default settings... rtdlights etc... They get owned so fast.
Like that mod on here a while ago that used dpm+framegroup files. If it had used iqm instead of dpm, then it would not have needed the separate framegroup files and would supposedly have been able to run on DirectQ, RMQE, FTE, and presumably soon QuakeForge in addition to DP. However, it uses an older dp-specific format and thus always has half the framerate of these other engines. Now, I'll agree that there's a tools issue here, but don't expect everyone to really aprechiate that.
Now, I'll admit that I don't know if it uses any qc extensions too or not. Considering it said 'DP-only', I didn't bother to check.

Everything is a compomise between performance, features, usability, code size, binary size, readability/maintainability, etc. DP just has different priorities is all.
But then, differences in priorities is what drives diversity, and diversity is good in the long run especially with all the engines that support similar feature sets.

[Ace12GA]

...Like that mod on here a while ago that used dpm+framegroup files. If it had used iqm instead of dpm, then it would not have needed the separate framegroup files and would supposedly have been able to run on DirectQ, RMQE, FTE, and presumably soon QuakeForge in addition to DP. However, it uses an older dp-specific format and thus always has half the framerate of these other engines. Now, I'll agree that there's a tools issue here, but don't expect everyone to really aprechiate that.
Now, I'll admit that I don't know if it uses any qc extensions too or not. Considering it said 'DP-only', I didn't bother to check.

Everything is a compomise between performance, features, usability, code size, binary size, readability/maintainability, etc. DP just has different priorities is all.
But then, differences in priorities is what drives diversity, and diversity is good in the long run especially with all the engines that support similar feature sets.

That would have been my mod most likely. The primary reason I used dpm with framegroup files was: 1) easy to code several models with 100+ frames of animation each. 2) Skeletal animation as opposed to vertex animation. 3) Familiar tool chain for me at least. I have been building Half Life mods for a long time, and have made literally hundreds of Half Life and Half Life 2 models. I have worked with old mdl and md2, and even md3, and the limitations, tool chains, and general pain in the ass to produce a model in those formats makes it so much nicer to export some smd's, run a tool, and boom, .dpm file ready to go into the engine. No vertex swimming so apparent in old mdl and md2, and no even md3 to a lesser extent, and easy to access from code.

I looked at iqm, but the tool chain is not there. Even if they supported a simple smd compiler, that would be a huge step. There are smd exporters for Max, Maya, and SoftImage. Smd is an ascii format, easy to parse. The source to valves mdl compiler is readily available to see how they work with smd files, etc... Sadly, if I was a real coder, and not a hack, I might even try building an iqm smd compiler; however the truth is I am not that guy. I would love to work with iqm to support more engines, but the tool chain breaks it for me. I would love Quake engine projects to support Half Life mdl files, but none do.

From an artists perspective Quake engine projects are neat, and difficult to work with; the tool chains are poorly documented, and generally for tools they do not use. No, I don't expect to change that, but that is why I used .dpm models, and framegroups. While it may be an older format, it is the easiest to work with from the artists perspective.

EDIT: I am going to leave my main post unedited, but after looking at IQM again, I see there is an smd compiler... so uh.. oops. Safe to ignore 50% of my rant... Regarding DirectQ, DirectX MS only. What about Linux? For me, Linux support is a must.

[goldenboy]

Nobody hates DP, it is just not the best engine to run *heavy* maps / mods (such as RMQ when it still worked in DP). Which is regrettable since DP is otherwise rather cool, but it is just a tradeoff I guess.

IQM: It has a Blender exporter, and it is supported in Noesis. I'm not sure how DP handles it, but in RMQE and presumably DQ it is a drop in replacement for .mdl.

[Spike]

I would love Quake engine projects to support Half Life mdl files, but none do.

FTE does. It even has (csqc) extensions for controlling the various bone controllers/legs.
However, its old code and ought to be either rewritten or stripped (it doesn't mix well with other features). I doubt it even still works as its been a while since I tested it, and the backend got rewritten fairly significantly since I last did... Still... old versions support it! Tbh its been ages since I used any of fte's halflife-support. :/

IQM is a drop-in replacement for .mdls in every engine that support it, including DP. Same as .dpm.
Really though, .framegroup files are there to fix omissions in imperfect formats rather than a real feature in their own right. You shouldn't and don't need to use them when you're using IQMs, which makes everything easier for the artists making the models.

[Ace12GA]

IQM is a drop-in replacement for .mdls in every engine that support it, including DP. Same as .dpm.
Really though, .framegroup files are there to fix omissions in imperfect formats rather than a real feature in their own right. You shouldn't and don't need to use them when you're using IQMs, which makes everything easier for the artists making the models.

I've been playing with the IQM stuff, and I see some real issues with the format already. It does compile smd's just fine, which is great, but. There is no way to rotate the mesh and animations on compile. There is no way to adjust the origin on compile. You can tweak the framerate and if the animation should loop, which is great. Without the ability to tweak the origin and the rotation though, its pretty useless to me.

As an example, I have these options in pretty much all of my models at compile time for .dpm.

Code: Select all

scale 1
origin 15 -115 170
rotate 90

This is useful because I can tweak the viewpoint of the weapon without going into the modeling suite and tweaking every single animation file, and reference mesh file, and re-exporting everything.

If there is a way to do this with IQM, please do tell. It is what is stopping me right now.

EDIT: Oh joy, the iqm files I have generated all crash Darkplaces (latest autobuild as of 20 minutes ago).

[mh]

The source to valves mdl compiler is readily available to see how they work with smd files, etc... <snip> I would love Quake engine projects to support Half Life mdl files, but none do.

The major problem with that is Valve's SDK license. It's just not possible to build on anything using code, info or tools in the SDK as the license requires that the end result should work with HL and HL only. So it's not a technical limitation, it's a legal one, and HL may be an old game but it doesn't mean that Valve won't go after you.

[Ace12GA]

The source to valves mdl compiler is readily available to see how they work with smd files, etc... <snip> I would love Quake engine projects to support Half Life mdl files, but none do.

The major problem with that is Valve's SDK license. It's just not possible to build on anything using code, info or tools in the SDK as the license requires that the end result should work with HL and HL only. So it's not a technical limitation, it's a legal one, and HL may be an old game but it doesn't mean that Valve won't go after you.

You are of course correct. I was referring to it as a working example of how to handle smd files, not as a code base for tools outside of Half Life.

EDIT: I started a thread over in the modeling section to cover this discussion so as to not ruin this thread with needless discussion.

http://forums.inside3d.com/viewtopic.php?f=13&t=4871

[toneddu2000]

I really didn't know about all of these DP's limits! So, if I understood correctly DP is great for small maps with a rather low number of rtlights and a 30000/40000 max tris per scene, right?

@goldenboy: thanks for the link at simonoc.com, I love that site! But I think that (premitting that the Bridge crane map is a total masterpiece), a thing is to create a single piece of game art, and another thing is to create a game. Create an entire game TODAY (like Crysis 2 or Battlefield 3 just to make two examples)with radiant & CO would be impossible, because now 3d editors have completely left the concept of "grid units" and "squares volumes" which still is the main focus on radiant. Yeah, I know, radiant level designers can also use obj for level props, but is killing time process and: (serious) terrain generator? dynamic vegetation system(like crytek editor)? Good physics engine? There LOTS of features that miss today
According dynamic sun light: http://www.youtube.com/watch?v=XTH7T82222gcheck this! It seems impossible that was made in Darkplaces engine! Anyway I can't understand how Blood Omnicide team did this (I asked via mail but no response )

[mh]

if I understood correctly DP is great for small maps with a rather low number of rtlights and a 30000/40000 max tris per scene, right?

"Great" is relative. DP also makes gameplay-changing modifications to the engine, so it's not really suitable for everyone (no engine is).

[frag.machine]

The source to valves mdl compiler is readily available to see how they work with smd files, etc... <snip> I would love Quake engine projects to support Half Life mdl files, but none do.

The major problem with that is Valve's SDK license. It's just not possible to build on anything using code, info or tools in the SDK as the license requires that the end result should work with HL and HL only. So it's not a technical limitation, it's a legal one, and HL may be an old game but it doesn't mean that Valve won't go after you.

Regarding this: i'd keep an eye in the ongoing Google x Oracle case about Java patent/copyrights violation on Android. I see a great similarity (Oracle claiming rights over Java API's - not the Android implementation itself - and Google claiming fair use, in a nutshell), and if Google wins, is my understanding that this opens precedents to turn void any restriction the Valve's SDK license could impose over any "clean room" code implementation covering their file formats.

Actually, AFAIK file formats cannot be copyrighted/patented; that's why LibreOffice can feature MS Office compatibility, BTW.