Solve static-vertices in stencil shd dilemma
Blitz3D Forums/Blitz3D Programming/Solve static-vertices in stencil shd dilemma
| ||
| This are some thoughts I want to write down right here. Often we find a certain stenil shadow system not useful for Blitz3D because of animated Models and their Vertices, because Blitz will return only the vertex coordinates of the intial Pose of the Mesh. The solution is pretty simple, but it requires that the Vertex Locations are read and handed over to the stencil code by Blitz: Right after loading the Animesh parent a pivot to each Vertex, then do all animations and store all the dynamic pivot positions in arrays. The Arrays or types can be accessed with a substitute VertexX() etc. function. Of course, the pivots are only required to get the positions. after that they can be deleted. It's almost trivial. It may look like a waste of ram., but actually array access will be much faster than calculating the vertex positions from the animation. This method is inaccurate to some degree because Vertices may be weighted, but Pivots will be parented to a single bone. But it's still much better than no vertex info at all. And for the NPC Animation design I would suggest not to use too many weights per vertex, this is going to slow down the game a lot, BTW. |
| ||
| Thats a good idea, but one has to wonder why a new generation of blitz3d hasn't been created by now. |
| ||
| My method: replace the entire B3D animation system with a single-surface version (i.e. combined multiple instances of a character into one surface, so that rendering speed isn't hurt) that uses VertexCoords. This should be slightly faster than the above - if you simply replicate the animation calculation, it's being done twice. If you replace it, it's only being done once. EDIT: I should add, one other thing I like about this idea is that it allows a lot of otpimisations to suit one's own system. For example, who uses bone scaling? So there's one calculation I don't need in my own game (you could add it...). The shadow volumes can use the same engine, but without a mesh normals update (because they don't display) and with a section that casts them away from light (because I know that in my system all meshes will be closed and "safe"). Last edited 2010 |
| ||
| That's an interesting idea : position pivots at vertex locations initially, then parent to relevant bone pivot (somehow need to know though which bone a vertex is parented to though) and combined with Yasha's method of creating and deforming vertices on a single surface set of characters based on the pivot locations...hmmm still will be slow but nice idea, and good for shadows. |
| ||
| Yasha, your method is consequent but it also means a lot of extra development time. Sometimes top code is flowing at high speeds right out of my finger tipps, then again, especially when studies of other peoples docs and or code is involved, I easily get stuck, so writing a complete Animation handler for skinned, boned Animeshes, would mean a lot of work and time to me. But of course, I highly respect such an effort. In the code archives there are some samples on how to save and load animated B3D without to use the Systems Commands, I think. As a quick solutions I still see some use for the Position Tables hack as suggested in the first place. I have to say, using a single surface for similar AniMeshes is a very good idea, because this would allow to use much more NPCs in a scene. Wayne - you're right. Although there isn't much I miss in Blitz3D. I do miss shaders. I do miss a native, fast shadows solution. Access to a Deth Buffer would help. But that's only in DirectX 8.1. Blitz3D is based on DirectX7. Mark would have to rewrite the whole thing, for DX9? that's almost as outdated as DX7, whereas DX10 is completely uncompatible to older machines and Osses. It is also the ecenomy that tries to force people to buy new hardware and new software as much as possible. Then Mark made BMax. A good compiler. There was also Max3D in the development. It seems like it may have become obsolete to a certain degree when BMax was already available and people started to wrap other engines, such as the XORS engine. There are many engines out there that can be used with many languages, including BMax. And there was also MiniB3D for BMAx, allowing people to migrate from Blitz3D to BMax with their projects, at least partially. So I guess that's why there is no new Blitz3D Version. I think it would be possible to write something like Blitz3Dx9 with BMax, it's just a big lot of work. Blitz3D is however still my favorite Language since I can do almost everything with it and we've got a code base with tons of goodies an code jewels. Just the shadows bit needs a solution IMHO. I have Sswifties Shadowsystem as well as FastExt plus some volume shadow solutions, like DC's, but none of them makes me really happy. Eighter they are Stencil, what I don't want (at least not software stencil), or they are software-mapped and slow. I am very optimistic that there will show up new shadow systems, probably better ones. Support for DirectX7 might be something rare in the future, but it's the same with DirectX9, even from Win32 to Win64 there are tons of issues, so if you really want broad compatibility, Windows may not be the best platform, unless you design games only for the latest standards. And I thnk it's getting more and more a matter of industrial strength capabilities in your company to make use of modern hardware power: you need a lot of good professional coders and designers for a fullfledged DX10 Game that actually has 4 GB game data on a DVD. If you haven't got enough workers, the gamedesign is going to take too much time and you'll release your DX10 Game when DX13 just has been decared the new standard. What I want to say it: if DX7 Support is my problem then I might use an other OS right away, how about a game engines that comes with it's own OS? Thats possible with a bootable linux disk, or even based on FreeDOS (tho this might seriously shock the users, dos :) ) |
| ||
| BTW just an additional thought: There may be a further program with the Idea presented initally: Yes, we can do that, but since DX will load the meshes with an inconsistent enumeration of surfaces, we will never really know which vertices belong to which surface. Surface identification must be performed (eg. using texture paths, probably combined with properties like CountTris etc.), a lookup table must b used for indirect access of the vertex animation data. (Tho, skinned animated B3D Characters usually have only one surface, then again, right in my game I got 2 of them, for face texture animation). It seems to be tricky but at least not impossible. |
| ||
| THis is all way beyond me, at least in terms of application. I understand what's going on, but my experience with animated meshes is pitiful, and manipulating them even more so. But the whole topic is really interesting nonetheless. Blitz will return only the vertex coordinates of the intial Pose of the Mesh replace the entire B3D animation system with a single-surface version (i.e. combined multiple instances of a character into one surface, so that rendering speed isn't hurt) that uses VertexCoords. I imagine, that with larger, complicated meshes, this would involve possible less detailed textures? Or can separate textures be applied to separate areas of a single surface individually? (I know this isn't the "point", but just seemed to be a possible issue with the proposed system) and: Aren't UV coords always local? i.e relative to the surface itself, rather than any real coordinates? I dunno, I'm just curious :D |
| ||
| I imagine, that with larger, complicated meshes, this would involve possible less detailed textures? Or can separate textures be applied to separate areas of a single surface individually? (I know this isn't the "point", but just seemed to be a possible issue with the proposed system) The idea was that you'd only use a single surface for two instances of the same character mesh (and therefore texture), in order to get the same surface-count advantages as one does with normal B3Ds using CopyEntity. There's no reason why combining multiple meshes into one surface for animation ought to be impossible, and it actually might be a good idea that I hadn't bothered to consider for use on lower-res meshes (thanks)... but it's not what I meant. |
   |