Jason Z

There are a number of ways that you can eliminate geometry from the pipeline before it gets to the pixel shader.  The most likely are related to the geometry not being within the clipping volume after exiting the vertex shader.  I see some of your vertices after the VS have a w value of > 1.0, which means at least some of the vertices are outside of the viewing area.  Double check the output vertices to ensure they are as you expect them to be.

 

Next could be that the vertex winding is not correct, and the triangles are being eliminated for back face culling.  For debugging you can disable culling in the rasterizer state to ensure this isn't the case.  This most likely isn't the issue since a cube would have at least partial geometry showing up from either the front or back triangles.

 

Finally, you have to have the rasterizer generating the pixels to be invoked in the pixel shader.  This requires that a viewport be set, and that you aren't using failing the scissor test.  Double check that you aren't configuring the scissor test to be active, and that you have set a valid viewport prior to drawing.

When I use the Gaussian filter to blur a line(1-2 pixels) in the whole black background, the blurred line is dark and it's "glowing" range is small. Then I compose the tow lines, the final effect is not as clear as the game's. May be I missed something?

I haven't read the book, but I will check it later.

Anyway, thanks for your reply.

Can you post a screenshot of what you are getting?  I think we could easily work through the issue.  I also think it would be worth your while to check out that chapter - even if you just skim through it, there is some good information in there.

That is what is usually referred to as a 'bloom', and it is more or less just using a Gaussian filter to blur the colors.  There is a sample chapter about how a similar effect is used in the game Tron from way back in the original GPU Gems book, which you can find online now for free.  It tells you lots about how to implement such a system, and should get you on your way!

@Steve: I think you are mixing two arguments, and that we are agreeing more than disagreeing.  Your experience is that you started out with one API (I guess D3D9) and now there is D3D11.1 - so your efforts are socked into the D3D9 level of effects.  If you were using a well designed engine, the pain of upgrading to a new API would be significantly decreased.  That is the whole point of an engine, to decouple the game itself from the reusable parts.  On a side note, I don't think there is any need to update in this case, as there are still quite a few D3D9 based games being released...

 

One other point that I wanted to make was regarding hobbyist vs. indie vs. professional (Juliean touched on this too).  If you are working on something as a hobbyist, then by definition you are doing it because you like the topic and want to do it.  If you are trying to create a product and sell it, then you are more like an indie, where you are making more of an investment and want to get monetary returns on it.  And of course, the professional makes their full-time paycheck from working in the area.

 

I have personally been a hobbyist for a very long time, and moved into doing professional work more recently - skipping the indie stage.  It sounds to me like you are more focused on being an indie developer, which takes a totally different perspective than a hobbyist.  The OP is looking for perspectives on hobbyist development, so I still think he should lean towards developing an engine as a learning exercise.  He clearly seems motivated enough to knock out a few games here and there, so it is also clear he is learning from doing.  I say, keep it going and enjoy the ride.

 

If you are having trouble finishing your game, is it because you don't have enough time to put on the project, or something more like feature creep?  Identify what the problem is, and take steps to handle it!  I want to see your game on the (digital perhaps) store shelves!

Well I hate to take the ratings hit, but I think people who give you the opinion to work on your game as an engine don't ship many products.

 

I won't rate you down, as I think it is productive to discuss counter opinions - so I would also suggest that others don't rate you down either.  To be perfectly honest, I don't work in the games industry, so I haven't shipped any games.  I have however build and delivered many diverse applications that use 3D rendering functionality.  So you are right, I can't speak to game development, but I most certainly can speak to software development that utilizes reusable rendering routines and algorithms (i.e. an engine).

 

So are you implying that you don't have an engine?  You just work on one project, and when its time for another project you just take the existing project and modify it?  What if you find a bug in your rendering routines - do you have to go back and make the same changes to a bunch of different projects?

 

It seems a bit silly to me to make the leap that anyone that tries to properly design a reusable library somehow isn't successful at delivering the end product.  In fact, I would say the opposite - having discipline and considering a design aspect of a library has always driven higher productivity in my experience.  You mileage may vary, but when you have to support many simultaneous and different projects with some common functionality, then I think it only makes sense to consider that common functionality as an engine...

I think there was an AMD demo a while back that showed off parallax mapping with cobblestones, and it was used for rendering a rainy street scene.  You can check that out as a source of ideas for how they did it - I believe Natalya Tatarchuk was the author of the presentation that I read.

Here's my honest opinion. Focus on results, nothing else matters (especially correct usage of const). You see, all the end user is going to see is the results. Most likely nobody else but you will ever look at your source code, so don't waste time making it obsessively neat.

I think you need to take this in context - results are what the end user will see, for sure.  However, if you are making an engine, that means you are planning on re-using it on more than one project.  That means that your end users will actually be other developers (or yourself if you keep it as a hobby).  In that case, I would highly, highly recommend going through the exercises that you are describing here and consider different aspects and designs that you could implement.

 

This makes you think more about how you are doing things, gives you more and more experience with the language that the engine is written in, and helps you learn more about the API you are using.  These benefits may not be tangible in the end result of a rendered frame, but they will certainly be tangible in your development experience as well as your debugging of issues during development.  So I would agree with Steve that output matters, but disagree that it is the only thing you should focus on!

It looks like the transformation for the second bone is applying a mirrored transformation somehow.  Perhaps this is due to a difference in conventions between your engine and 3DS Max?

I have also seen performance improvements as well from doing state management in my engine.  I discussed this a few weeks ago in my journal here on GDNet, with follow up performance metrics here.

 

The fewer API calls you make, in general you will save time. 

It totally depends on what you want to do with your rendering code.  The best way to structure your code is to make it flexible so you can choose the right tool for the job at hand.  My engine allows for both of the mechanisms that you mentioned, but in my case each object carries around its own material information.  The 'state manager' then ensures that there aren't multiple API calls made to set the same data more than once.

 

The latter of your two ideas is usually called an immediate renderer or something similar.  It is generally a higher level object that simplifies the usage of the graphics hardware at the cost of performance.

The random number can be obtained by having a 'random' texture and applying an offset to the texture coordinates used to look it up based on time.  So over time the random value supplied to each pixel will change.  You can then determine what size of texture works best for you, and how fast the offset should wrap around.

 

As long as you are capable to get a draw call that can be used to select the appropriate pixels to get executed in the pixel shader, you should be able to use this technique to add or reinitialize particles.

Hi Tiago,

 

I found out that it is indeed not possible to do the pixel history when a pipeline configuration uses SV_InstanceID, SV_PrimitiveID, or SV_VertexID.  This is due to the fact that these are generated on the GPU rather than by the driver, complicating the ability to recreate the pixel history.  Apparently PIX had the same issue, although nobody was sure if it has been documented prior to this.

 

That's probably not the answer you wanted to hear, but at least you know what to expect in these three cases now.  I hope that helps...

That is typically only needed for objects which have transparency (or use blending in your case).

 

EDIT: There is actually an algorithm called "Order Independent Transparency", but it is a very heavyweight algorithm for doing simple sprite rendering.  Still, it might give some insight into the problem if you read up about on the topic.

If you are fixed on OpenGL, you can safely disregard this option

 

Hieroglyph 3 is an open source engine that makes it possible to add new effects / rendering techniques relatively easily - but it uses Direct3D 11.  There is a number of different effects already available (deferred rendering, light prepass, tessellated terrain surface, water rendering, voxel texture rendering, etc...), which can be used as a guide for implementing something totally new.  There is a small community and moderately active discussions, so if you have questions there is help not too far away.

 

In full disclosure, it is my library... but I still think it may be able to help you with your testing.

Are you sure that this isn't how it's supposed to look?

Are you asking a question, or telling us that your implementation is correct?  It isn't clear to me (or anyone else I think) what your motive is for writing this thread.  If there is something about your results that seem wrong to you, then please ask about it.  If this is a thread for you to demonstrate your implementation, then put that in the description.

 

So far, I haven't seen you really ask any substantive questions - please help us to understand what you want.