[OLD SHIT ENGINE] Pointless arena shooter

[leileilol]

I'd like to replace the awful baked breast physics with dynamic jigglebones someday (also for skirt, ears and hair). The only real issue is MDR not having hierarchy information so the IK stuff would have to be excruciatingly defined externally. that and I suck at vectors and the physics. IQM still not an option and isn't appropriate for lacking tags and being expensive. I'd also like the physics to be optional as well, since I am still targeting the Pentium II as baseline, which has performance in line with the Raspberry Pi. A lot of my changes to the code happen in renderer/ and cgame/ so hopefully the gameplay is not affected.


I also have strafing animations on the way too. Avoiding the 'small and stiff' look Q3 and OA had is something I would love to do, epecially when there's free games like MicroVolts, LoadOut, and TF2 out there, with overly expressive characters. I have to match the bar set within the technical and gameplay limitations

[toneddu2000]

I don't know the MDR model format, is what you used? Why using IQM model format is expensive? I thought IQM was the perfect choice to add skeletal models to Quake-related engines

[leileilol]

MDR is the finished implementation by Raven Software for Star Trek Voyager Elite Force. There's significantly more pipeline support for MDR than there is MD4, and MD4 support was stripped out of the source already. MDR is also very compressed and efficient for memory usage - which is kind of the whole point. It also supports internal LOD meshes (saivng even more memory by not having separate _1 and _2 files to load), but I am unable to export MDRs with those for the time being.


For example, my pipeline for MDR models is actually using Noesis to convert my IQMs to MDR, complete with specific bones functioning as tags. My model is around 2000 triangles and in total with the textures (including icons and red/blue skins, each skin being 512x512), it zips nicely to 696kb. A MD3 version of the same thing? Zips to 2,283kb, and takes even more memory when fully loaded.

[toneddu2000]

ah, understood. Any good example of a memory efficient implementation of IQM in a Quake engine?(Sorry for the off-topic)

[leileilol]

IQM is optimized..........


.......for hardware vertex buffers, and not for the struggling cache of the P6 architecture


likewise for OA3, MD5, SMD and PSK are out of the question. especially MD5.... the most suggested format without insight put through on why

For me, it's not very fun retreading on model format politics. Different formats don't automatically turn a model great, it's how they are used that matters, and my choice for MDR is purely for efficiency reasons. It exists, I can export to it, and it's been proven to work in a (rather excellent) shipped title from 14 years back. My treatment has been mostly PS2/GCN-level assets rather than the 400-900 poly borgs and hazard teams and 7of9s and it seems to work very well for my purpose.


now if I could just have LODs imported somehow.... my lod plans are extreme on the contrary. I want to go even lower than Q1 for them.

[Spiney]

Maybe you'll like this. David Rosen talks about procedural animation. Kind of amazing how much movement he gets out of only a couple of keyframes.
http://www.gdcvault.com/play/1020583/An ... e-Approach

[leileilol]

Sounds overkill. The secondary animation stuff i'm seeking are basic bone moving rotating stuff seen in the first Virtua Fighter and Dead or Alive games (93 and 95 respectively). It should never be more complex as feet aware of surroundings

[toneddu2000]

Thanks for posting this. It's the most incredible thing I've ever seen. About everything. I knew Overgrowth was wonderful, but I would have never imagined how detailed the physics/animation engine was! And he made everything by himself!
I think that an approach like that is barely impossible on quake engine...

[frag.machine]

[Spiney]

Yeah, I'm not suggesting you go fully procedural or anything. Just throwing it out here, there's some simple yet clever ideas inside. If one or two are applicable that might be a win.

[leileilol]

There's some things I don't want to do. I'm targeting older and crippled CPUs so a lot of things are still off the table.


Also, there's less places to abuse traceline in id Tech 3...

also all this offtopic talk buried . I thought more would be excited over me programming a Source-esque feature in a GPL engine

[qbism]

[leileilol]

Moving the eyeball origin was actually a good workaround, maybe remodeling the eyes as icospheres might help a bit.


Also, the pipeline for defining the eyeballs is much easier than Source and is still similar In Blender one can just get eye origins by making spheres, moving them where the eyes are, and grabbing the origin numbers and sticking them in an animation.cfg. There's two eyeball surfaces that both should have their own eyeball shaders that have two different tcGens (lefteye and righteye). Fortunately both eyes can use the same texture, unlike Source in which its material system requires two unique eye textures.


Can Darkplaces ever get eyes implemented?

[leileilol]

Eventually someone's going to have an issue with some of the new player model designs. Cue the new r_suggestiveThemes cvar to make that optional.



Default is 1, because the modest versions would introduce so much seams to rework the mesh and doesn't necessarily look better.

And during progress of this feature...



Also in the optimization side, I've added r_iconmip, which is like picmip, but for 2d icon assets. r_iconmip 1 default, determines mip amount by resolution automatically. Any value above forces it (like r_picmip). r_iconmip 0 turns it off and leaves it alone for vanilla behavior. For 1, it does not go further down than 32x32 (compatibility with Q3 mods)

[goldenboy]

I like the garment on the, erm, "modest" version. Clothes can look cool, too.