I've been programming for about 8 years but only recently started working in game development, so I'm still learning and familiarizing myself with certain graphical concepts. That being said, I apologize if my question sounds amateur-ish but I've been looking in different books and online resources and haven't been able to find anything that helps me understand what I'm trying to learn how to do.

This post may help you understand: http://www.youtube.com/watch?v=-Q6ISVaM5Ww

I'm trying to understand the concept behind using 3D rendered sprites and importing them into my content pipeline, so that I can display them and draw them using spritebatch. However, I have been having difficulty understanding how to achieve this in code. Any sample code or a more in-depth technical explanation would be nice. I can easily render objects in 2D and even program a 2D tile engine, but when it comes to dabbling into these 3D concepts, I'm treading new ground.

If anyone could just help me out to understand better that would be much appreciated. Thanks!

Hi,
Perhaps it's just me but I think "3d rendered sprite" is somewhat ambivalent. Do you mean 3d models, or 2d (Texture2D) sprites that look 3d and have shadows, lighting etc?

When you use 3d models, you don't use spriteBatch to draw them. Instead, you traverse all meshes and meshparts of your Model objects and draw them, typically using a Camera object to generate the view. You'll find plenty of 3d XNA tutorials around the web, for instance here: http://creators.xna.com/en-US/education/catalog/?contenttype=1&devarea=6&sort=1

Sorry if I misunderstood your issue here!

I understand what you're saying, even though I'm not sure how to implement that particular scenario. What I mean is 3D models that are at some point rendered to a single viewpoint in software like 3DsMax, milkshape 3D, or Blender, and then loaded in the game for display in only one view. I'm not talking about actually full-fledged 3D objects here, more like 2.5D for lack of a better term, but I'm also not talking about an isometric/hex type of view ratio either, which I DO understand.

What I'm trying to figure out is how the programmer achieved this in the video link that I posted, because from what I can tell, and from what he stated in his comments, the models are rendered in 3D, with normal maps, height maps, etc, and then somehow used in his drawing method to place them on the screen and have shadows, lighting, etc. as you mentioned. I'm confused how this works and quite frankly, I've been searching online for about 2 weeks off and on, and have checked many books dealing strictly with design concepts in DirectX and still haven't found anything related.

I haven't been able to find a duplicate instance of this design-method and I'm wondering how it works and how feasible it is- because from the video it looks amazing- and from his explanation, sounds not that hard, if the underlying concepts were explained a bit better.

ScRiblzzz:

I understand what you're saying, even though I'm not sure how to implement that particular scenario. What I mean is 3D models that are at some point rendered to a single viewpoint in software like 3DsMax, milkshape 3D, or Blender, and then loaded in the game for display in only one view. I'm not talking about actually full-fledged 3D objects here, more like 2.5D for lack of a better term, but I'm also not talking about an isometric/hex type of view ratio either, which I DO understand.

What I'm trying to figure out is how the programmer achieved this in the video link that I posted, because from what I can tell, and from what he stated in his comments, the models are rendered in 3D, with normal maps, height maps, etc, and then somehow used in his drawing method to place them on the screen and have shadows, lighting, etc. as you mentioned. I'm confused how this works and quite frankly, I've been searching online for about 2 weeks off and on, and have checked many books dealing strictly with design concepts in DirectX and still haven't found anything related.

I haven't been able to find a duplicate instance of this design-method and I'm wondering how it works and how feasible it is- because from the video it looks amazing- and from his explanation, sounds not that hard, if the underlying concepts were explained a bit better.

That makes sense.

I've been working on implementing something like this since reading your reply.

What is the best way to set up an editor so that when the user clicks an area it allows the user to create a set of vertices that create a 2D geometric object, and store them into a list or some array for later use in collision detection?

Is that the method of bounding a character on a level in games such as FF7, 8, and so on? Specifically, the games in the series that had highly detailed pre-rendered backgrounds that were obviously not tile-based? I believe they are Final Fantasy 7, Final Fantasy 8, and Final Fantasy 9. All the ones prior had tile-based, and I'm pretty sure FFX and later are full 3D. But in FF7 only the combat appears 3D, the sprites are 3D models, and the background looks like just a 2D image.

After answering the previous question, would it be more efficient to use that particular method, or would it make more sense to use a masking layer with white/black, white being areas that a character can move freely, where black would obstruct/prevent movement of sprites/model?

Thank you.

Also, I've read that using 'if' statements too often in frequently called methods can cause unnecessary loss of FPS due to CPU's pre-loading instructions before they're needed, and that if you are going to use many 'if' statements in your loop, they should be calculated as true and execute most of the time, rather than have them coded in such a way that whatever is in the scope of the if statement is rarely called. Actually, I read that from a book I'm using to learn 3D, physics, and etc. by Andre Lamothe.

Also, a lot of his other optimizations seem pretty specific to C/C++, due to inline assembly, bit-wise operators, and pointers being used all over the place.

Would it be better to switch to C/C++ (I have experience with the language) for learning to create games, rather than hinder learning the low-level stuff by using XNA? I'm starting to feel like it might be better to focus on DirectX technology, and using C++ for the games, and C# with XNA more as a type of pseudo-developement environment for prototyping/testing. Any thoughts?

How much different is it really to just create the same engine natively in C++ and setup DirectX and make all the calls manually? I understand I'd have to setup an hWnd for my window then and manually setup a callback function to handle windows messages, but I've been using the windows API for awhile and if that's all that it would take, plus the overhead with setting up access to DirectX, then I would prefer this. Granted that all of the functionality that is in XNA exists in DirectX and is accessible in a practical sense. If for instance, it requires jumping through hoops to achieve something in DirectX that would be easily achievable in XNA and actually hinder the developement process, then I'll stick with C# and XNA.

Thanks

Another method you can use is after you’ve created your highly detailed scene and rendered the beautiful images is to simplify the mesh and use that for the depth values and collision detection.

I doubt if it’ll matter too much which language you use.

Erglegrue:

From what I can gather, all the objects he has in his level was made in a 3D modeler. He rendered them with just their diffuse texture colors, then he rendered them with their world space normals, and then once more with their depth values.

So he now has 3 textures per object : Color, Normal, Depth

From that point, he does what's similar to deferred rendering. First he draws all the "Color" textures into a render target. Then he draws all the "Normal" textures at the same coordinates, into another render target. Finally he draws all the "Depth" textures into another render target. He also writes the depth values to the depth buffer, so the objects appear to intersect in 3D. He then uses a shader which samples from all 3 render targets, and computes the lighting on each pixel.

That's a nice summary of the process involved. Can anyone provide some more specifics about the best way to go about designing the lighting pixel shader? As I see it, this is the critical part in achieving this effect, and I have a couple of doubts about it:

1. How to incorporate information about different light sources in the shader? Are light emitters rendered into yet another texture (e.g. as gradients)? Or passed to the shader in some other way?

2. What is the best way to compute this kind of per-pixel lighting? Just multiply the light gradient at each pixel by the normal map and depth maps?

3. Is there any obvious way to extend this for shadow-casting in the pixel shader? The author mentions this possibility in the video and hints at a possible next video where he would display the technique for shadows, but alas, it never made it to youtube.

Thanks in advance for all the help :)

Best regards,

Gonçalo