DXW Feature suggestions, requests

[bladder]

Hi everyone

If you have any features that you think would be cool and useful for the dxw to have, then mention them over here. At the time of this post, the dxw is on version 1.5 and the features that are complete for version 1.5 include

- A SpriteAnim class for 2D animations.
- A TileMap class for creating 2D levels out of textures and indices.
- Added 3D tile support. Now you can render the tiles in 3D mode. (not TileMaps
- Added a very robust vertex creation system.
- A SkyDome class for creating atmospheres for different times of day that supports interpolating between different atmospheric presets over a time period.

Those are the main additions, there have been numerous other additions as well, bug fixes, performance enhancements. And hopefully some other features (including octree, quadtrees and height map based terrains) are to be added before the next release.

So lets hear it...

[MatteKarla]

Make core, input, gfx to singletons.

Why not a simple scene-management system?!
For example a Node class you can attach children to.
Then derive core and scenes from it.
(a node updates itself, then calls it's own children)

All scenes objects etc. would then automatically be updated and rendered, marked for death.

Do I make any sense?!

[Dima]

hi,

If this is going to be developed into a full engine, and not jsut a wrapper, then there are plenty of good things that it could benefit from

I would like to see some of the harder things to implement, like :

Skeletal Animation for a Mesh Class, these are tough to implement.
MD2 or MD3 file loading and animation would be sweet.
A Scene Graph would be cool, that used a vertex cash for batching geometry.
Terrains and kybox/domes are neat
Shadow Volumes, that for instance you can just pass a VB to and voila...
Maybe particles..
Quake3 map loading and fast rendering would be a saviour, must be very tough.

hehe, there are tons of other things I would love to see in this engine. It's coming along nicely, and the design is very stable. But I would rather some of these tougher things rathen than tile animation system which is fairly easy to implement. The console was a very nice addition, how about dynamic LOD, hehehe, ok getting carried away now..

love the engine,
Dima

[Dima]

On smaller scale things like Vertex Cash, Ability to render to texture, easy access to texels in textures, environment mapping effects, and maybe a sophisticated mesh class that can load md2 or skeletal animation files and play them, or generate shapes from code and apply deformations on them, like subdivision, hehe, getting carried away again...

[bladder]

Make core, input, gfx to singletons.

I was going to do that at the beginning. But I wanted each class to be able to be moved between projects as easily as possible. And using singletons actually complicates that goal. So I figured I'd just provide access to the needed classes through other classes. eg: the Scene class allows access to all major modules.

As for the scene management system, yeah, that woudl be nifty to have, I'll put it on the to do list.

[QUOTE[If this is going to be developed into a full engine, and not jsut a wrapper, then there are plenty of good things that it could benefit from[/QUOTE]

I think it's already passed the wrapper stage and entered the "dumbass engine" phase. ;)

Skeletal anims, anim blending, skydomes, terrains, and a particle system are already on the to do list. I already got the skydome up and running, with moving clouds that are generated at load-time.

Didnt think of shadow volumes, would definetly be neat ot have. I figured this engine would work exclusively with X files. Since you can do skeletal anims, blemding, and morphing with them, and therer's already a mesh class and animation controllers. I suppose having a tool that imports an md3/md2 into an x file and then lets teh engine load it would be a sweet adition though.

Your smaller scale stuff is all good though. A render to texture class would really fit the "Wrapper" image. Mesh classes are definetly in the pipeline. Probably by version 1.7 there should be a decent mesh class. For the next release Im working on run-time generated things, like skys, terrains, particles, etc...

[anubis]

A render to texture class would really fit the "Wrapper" image

i'd rather support the idea of render targets. the client shouldn't know about wether it currently renders to a texture or the framebuffer. making this transparent adds great amount of flexibility to your engine

[Dima]

how about a material/texture class that could easily add environmrnt mapping and dot3 bump mapping, and direct access to texel information.

maybe a math class, that would simplify some transform operations, ray casting and picking (like picking objects with mouse in 3D space), culling and maybe sorting algorithms.

I like the idea of having procedurally generated geometry, like shapes such as spheres and cubes, with ability to extrude, lathe, or subdivide.

stencil buffer tricks like screen wipes and shadows

fog control

water planes with ripple effects would be cool

maybe osme kind of procedural texture support

hehe, so many wishes....

[David Sleeper]

Hey guys I am new to the posts and the new site partner. Around the 1st I will be posting my little engine up as well as adding a little tutorial for the parts that are a bit confusing.

As of now I have written/modified code for...

-Bonned animated meshes using .x format
-Md2 file loader and tweening between frames
-Octrees for world object culling (still need to add a level higher up)
-Directinput, sound, etc (the basics)
-Fairly balanced AABB for world collisions (still need a fast build for tree)

coming soon...
-collide and slide for ellipsiods
-even faster culling (thus far it linearly passes through objects subsets created with an octree, soon it will traverse a quadtree with octree leafs - I will explain my reasoning later on)
-quicker build for AABB tree

[David Sleeper]

Oh I also forgot to mention. Unlike Bladder's wrapper/engine, mine isn't intended for everyone to understand and ease of use. It is for me to use. I will have explanation but the point is mostly to give people a chance to look at some of the more difficult problems (collisions, trees, etc.) and one persons approach to them.

Also if anyone is interested in good programming techniques and methods Bladder's engine is a clean and great example of a "how to" on programming.

[bladder]

Well finally you decided to register eh. The engine David has been developing on the side is actually moving at a super fast pace. It's like

Monday: Hey I got meshes loading
Tuesday: Hey I got skeletal animations working
Wednesday: DUde, the skeletal animations is causing trouble
Later on Wednesday: HEy I got skeletal animations with animation blending working!

BTW: Since David is here, you guys can start asking physics implimentation related questions B)

i'd rather support the idea of render targets. the client shouldn't know about wether it currently renders to a texture or the framebuffer. making this transparent adds great amount of flexibility to your engine

This sounds good. Have you implimented render targets like this? If yes, how'd you go about designing the transparency? If no... any ideas on how to design it?

how about a material/texture class that could easily add environmrnt mapping and dot3 bump mapping, and direct access to texel information.

Ok, the way you can currently access texels is by calling the Texture::TextureCom->Lock(), then using teh D3DLOCKED_RECT to access the texels. How would you prefer to access texels?

I mean like could you show some sample code how you'd want to be able to access texels?

I like the idea of having procedurally generated geometry, like shapes such as spheres and cubes, with ability to extrude, lathe, or subdivide.

People stop trying to turn the DXW into 3D studio Max!!

Anyway, two people have suggested this, would this really be a handy feature to have? Would it even be used as much as other stuff?

maybe osme kind of procedural texture support

Well currrently the CloudTexture class uses procedural techniques to generate a cloud texture, and the Init function has like 10 different parameters you can use to alter the appearance. So far that's the only procedural texture supported.

maybe a math class, that would simplify some transform operations, ray casting and picking (like picking objects with mouse in 3D space), culling and maybe sorting algorithms.

Definetly! They should start rolling slowly, but surely.

fog control

I don't really remember, but does the DXW 1.5 have the GfxDevice::SRSVertex/PixelFog() in it?

[Dima]

ok, about the texel access... Easy GetTexel and SetTexel functions with error traps would be nice to have. Functions should support any pixel format automatically. This isn't as fast as doing custom reads/writes, but it's very easy. Applying filters to textures would be sweet also, Imagine applying a simple blur filter just to the alpha channel of the texture, it's like having antialiasing for sprites.. This isn't hard to implement at all, I was just thiking it would e nice to have easy access functions to that, but not necessary :)

about the shapes... D3DX already has shape creating functions which are pretty easy to create, but they lack texture coordiantes.. To get textures on them it takes some code to clone the mesh, then access the verts and set the coords, very difficult for begginers. Having custom shapes can eliminate those difficulties, allowing people to create shapes fast and easy. IMHO shapes are useful for prototyping, or procedural world generation. Also, custom shapes could have options to be made from TriLists with Idicies, which could be all added to simple vertex cashe and batched together, imagine 1000 cubes, tough to render separately with good performance, but batched together, GPU is at work. Im not sure about batching D3DX shapes, i think they use a mixture of TriLists and Strips, Fans in some cases. Oh yeah, things like subdivision arent necessary, hehe, I was just going crazy with ideas, but a feature like that would be useful if shapes, and meshes has similar structures, then you could create detail geometry with small files sizes... Like a low poly count .X model, could become extremely smooth right from code. No necessary, but not many engines have this type of feature.

Billboard support would be nice and easy, with software tranfsormations and vertexcache batching it might be very benefitial. Batching is a huge performance booster, not many engines let you do that easily, like rendering 1000+ billboards, most newcomes have 1000+ SetTransforms and 1000+ RenderPrimitive calls. Easy access to fast batched geometry like that would be very benefitioal for many, and engine performance would be great.

My video card doesn't have hardware shaders (i have a gForce2MX) very old card, and yes I should get a new one, so I cant really say anything about implementing shaders, because I know nothng about them, and I can't even see the samples, but not everything is about shaders, alot of people stil have old video cards, so games should run, and look good without shaders. Most indie games are 2D, new ones are 3D, but most support old ass cards like TNT. This engive has a good enumerator so everything should be fine, I was actually thinking about suggesting to support DX8.1 so many older cards/people without dx9 (56k) modems, would be able to run the engine, but Im not really sure about that anymore, DX9 seems to have some sweet features, specially with shaders, so blah.

I'll think of some more selfish features, but for now i am very impressed with the engine, it runs very smooth, and bug free. Love the console, and easy to use code structure... plz, whatever you do, keep working on this engine, I would be glad to donate/write osme code to hel out. Also, I already started working on a game, should be playable soon, i'll share the code

[anubis]

to be honest i have no idea how to do it with directx... recently an opengl extension hsa been proposed. i would guess that there is a similar feature in directx. it shouldn't be to complicated API wise... a single call taking a texture handle or window handle should be enough.
as for the old video card. implementing an abstract interface for different code paths would be easy, non ?

[bladder]

to be honest i have no idea how to do it with directx... recently an opengl extension hsa been proposed. i would guess that there is a similar feature in directx. it shouldn't be to complicated API wise... a single call taking a texture handle or window handle should be enough.
as for the old video card. implementing an abstract interface for different code paths would be easy, non ?
Ok, to use render targets with dx you'd do this:


// pDevice is rendering context.
// pTexture is the texture interface you want to use as a render target
IDirect3DSurface9* pDestSurf = 0;
IDirect3DSurface9* pOld = 0;

pDevice->GetRenderTarget( 0, &pOld ); // Get old render target
pTexture->GetSurfaceLevel( 0, &pDestSurf ); // Get texture surface interface
pDevice->SetRenderTarget( 0, pDestSurf ); // Set texture surface as render target

// Do your begin scene, end scene, clear and flip stuff here

pDevice->SetRenderTarget( 0, pOld ); // Restore old back buffer

// Clean-up
pOld->Release();
pDestSurf->Release();


It's quite simple. It's possible to make the process even easier, by having some class remember the old back buffer and stuff. But ultimately, the client will have to be aware of whether it's rendering to the back buffer or to the texture. I think the tranparency is a great idea, just looking for some ideas on how to go about designing it. Do you have a link to the recently proposed extension for ogl? Maybe after I read it things will clear up more. Or maybe now that you know how render targets are done in dx and about the extension, you can give some input? The easiest I can think of having render targets (without transparency) is

// pTex is pointer to texture
pTex->BeginRendering();
// Render stuff
pTex->EndRendering();

Dima:

Woah! I really appreciate the input :yes:

Good point on the primitive shapes. I'll get cracking on it. And the batcher you provided earlier is alreay being (trying to be) worked into the dxw. I really like the new vertex system that has been implimented (granted the idea was not mine, but anyway), and I was actually thinking of ways to impliment a vertex batcher in this new vertex system. You're not gonna beleive this, but the new vertex system is actually fully templated.

The subdivisions, lathing and extruding I'm going to leave for another day (maybe David would like to take a crack at it?)I love the texture filterer idea though, and billboarding is definetly getting in the dxw.

Thanks for the input guys, it's really helping.

Also, Dima, since you have an gf2, I'd like to know if the new vertex system even works properly on it. Would you mind if I sent you the latest version (mind you it's pretty buggy) and you mess around with the vertex system a bit to see how well it works?

[anubis]

But ultimately, the client will have to be aware of whether it's rendering to the back buffer or to the texture

why ???
i mean sure... at some point the client tells the engine to switch to a texture but the rest of the client app should be able continue rendering without noticing the change. this is what i meant with transparency btw

[Dima]

Hey, i'll be more than happy to try out the new vertex system, so feel free to email it or link to my email DimaSafro at hotmail dot com.

About the shapes... there's already some tutorial code on how to make textures shapes, it's in DX8 though, but very much similar to 9.. Andy Pike (http://www.andypike.com/tutorials/DirectX8/009.asp), dude has more tutorials on things, but the shapes are pretty much done. Although he uses multi RenderPrimitive approach for some shapes like cylinders and cones, but it works well, don't know about batching ......

I like the idea of render targets, althoug I havent played with it at all, it doesn't seem difficult to implement with flexible results.

so yeah, feel free to send some code, i'll play with it

[bladder]

but the rest of the client app should be able continue rendering without noticing the change. this is what i meant with transparency btw

Ohh, ok. I thought you meant the client not knowing if it's rendering to a back buffer or to a texture. Anyway, rendering to the back buffer is pretty much the same as rendering to a texture in d3d. Once a texture is set as a render target, it's treated exactly lik the back buffer.


About the shapes... there's already some tutorial code on how to make textures shapes, it's in DX8 though, but very much similar to 9.. Andy Pike, dude has more tutorials on things, but the shapes are pretty much done. Although he uses multi RenderPrimitive approach for some shapes like cylinders and cones, but it works well, don't know about batching ......


Yeah, I was actually going to email pike to ask if I could just plop his stuff into the dxw :) Though dunno if he'll answer...

And thanks, Ill send you the code sometime today or tomorrow. (right after I get the damn thing to at least run properly...)

[anubis]

i knew that it was possible in directx but had now idea at all how. if it's easy to do than do it. it's a great feature :)