Jump to content

  • Log In with Google      Sign In   
  • Create Account

Super Llama

Member Since 13 Dec 2007
Offline Last Active Feb 26 2014 07:59 AM

Posts I've Made

In Topic: Can't get Quaternion Time Derivative to work?

24 February 2014 - 01:24 PM

Oh okay, I was wondering where that came from, that makes sense too. Thanks for the explanations, this is exactly what I needed to know.

In Topic: Can't get Quaternion Time Derivative to work?

24 February 2014 - 08:01 AM

OHH right, that makes perfect sense, thank you! I knew I was missing something obvious lol. I guess that means it technically works if you keep re-normalizing the quaternion and the game doesn't go longer than a few fractions of a second before updating the delta, but I guess using trig functions is inevitable if I want to do it right in all situations. I think I'll just construct a new unit quaternion from my angular velocity (since that only takes 5 math function calls) and multiply that onto it, unless there's a more efficient way I don't know about.

In Topic: [DX9] Multi-textured meshes, sampler index trouble

21 October 2012 - 11:34 AM

I did look into BSP's and such, but my main weakness is writing an editor for something rather than actually writing the system itself. My engine is very strangely coded and even the "easy to implement" things like bullet or lua would require far more work than usual to make them play nice with my system. I won't go into detail, but I have a very polymorphic exe that loads different scenes (including editors) depending on the "map file" you load. And the map file is not just geometry and entities-- it's basically an entire program, and may or may not have GUI's, physics objects, shaders, textures, etc., all potentially embedded inside them. I also have my own compiled scripting language specifically for creating these map files.

I guess my wacky interface wouldn't really be too much of a roadblock for implementing a third party tool if I really needed to, but I really just prefer making it myself because I can understand fully how it works. If anything in my engine is slow, I want it to be my fault and my fault only. I don't take the beaten path with coding, and I never have... I really don't know why. However, this doesn't apply with editors, and I'd much rather figure out a way to texture an exported hammer map than make my own new map editor. I suppose an additive mesh system suits the engine better the way it's built anyway-- the main reason I want multitex is because I want to be able to use hammer's excellent brush toolset, and the easiest way I can find to render it is using multiple textures.

I guess it's just time to give up on hammer and use static mesh pieces to build maps, that seems like it is still the best alternative to hammer and multitex.

In Topic: [DX9] Multi-textured meshes, sampler index trouble

20 October 2012 - 10:49 AM

My collision engine does allow for a mesh to have a separate triangle list for collision, but it's still 1 physobject per mesh. I pretty much code everything from scratch except DirectX and Windows, so I don't use third party libraries. It's just an Ellipsoid/Polygon intersection test, I don't have Poly-Poly collision yet and when I do it'll probably be convex polygons only. For now, though, the map file has one mesh that's already fairly low poly, and I've been using the same mesh for rendering and collision because of the fact that it's a hammer map exported into my format.

Technically if I were to take your suggestion of using a single mesh for collision and several for rendering, I would just have to give the collision mesh a nonrenderable mesh and set its physics mesh to the one I had been using, then fill the scene with a lot of non-physics objects set up for culling. Still, though, I'll have to figure out what criteria to cull based on-- I mean, I don't have any sort of area portal system and I'd rather not manually separate them in 3dsmax... though technically that is an option. Another idea though-- I did manage to get a W-based texture selector working using a massive switch case, but it only supports up to 16 textures because of the SM3 sampler limit. However, if I were to chunk the map into a bunch of culled pieces, it'd be easy to have less than 16 textures per chunk at least.

So to summarize, I'm thinking I could turn off rendering on my big one-piece non-textured map file, split it into a bunch of non-physical pieces, multitexture each of the pieces separately, then draw the pieces separately using frustum culling. Technically though if I make a few changes to the collision response I don't even need the one-piece physics object and I can just make the chunks physical as well. Do you see any problems with the switch-based per-chunk multitexture idea? Is swapping out a bunch of samplers per pixel shader painfully slow or something? It sounds like it would work to me, but that massive switch case does make me feel a little nautious :P

In Topic: [DX9] Multi-textured meshes, sampler index trouble

19 October 2012 - 05:42 PM

That's true, I hadn't thought of frustum culling. The main reason I wanted it to be one mesh is because the collision response is easier to calculate that way and it's also easier to export from 3dsmax in one piece rather than several. Cutting it into one mesh per triangle would be ridiculous, and I'm not really sure what would be a good intermediate step. I mean, technically I could make all maps using an additive scheme like the interiors in the Elder Scrolls games, using nothing but single-texture single-mesh objects all put together into a world... but I'd planned on using Valve Hammer Editor, which I'm very used to, exporting to DXF, opening them in 3dsmax and exporting to my format, then texturing them in an in-engine tool with special W coordinate stuff. It sounded great until I hit this obstacle...

EDIT: to restate-- I'm not sure where to divide a mesh up if I were to do so-- dividing it based on texture wouldn't help with culling, but dividing it based on culling wouldn't help me texture. Technically I could divide it based on culling and then use a texture atlas, but that's actually quite a bit of work...