Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Sep 2004
Offline Last Active Sep 28 2016 07:44 PM

#5068697 Frustum culling using a KD-tree

Posted by on 10 June 2013 - 11:03 AM

Hey, thanks for the reply.  I am still confused angry.png .


Say I build the kd-tree from scratch.  I have N entities each with their own AABB bound.  Would I construct the kd-tree using the position of the entities?  Or should each point of the bounding boxes be used?  To me, a BVH makes much more sense for frustum culling as the nodes represent an AABB.  Same goes for structures like octrees for example.  Each node represents an "area" in space.  With a kd-tree a node represents a split in one dimension.

#5052218 What should I do?

Posted by on 11 April 2013 - 02:12 PM

Sounds like you are interested in the actual game mechanics.  I don't think it directly deals with engine programming.  I feel like engine programming deals much more with the field of software architecture.  Game mechanics like the ones you've mentioned deal more with algorithms.


There are countless aspects to game programming that deal with computer science.

Just thinking of the different specializations offered at my school, here are the ones I can think of:

- Software architecture

- Computer graphics

- Computer vision

- User interface programming

- Algorithms

- Sound engineering

- AI / Machine learning



#5051246 Best way to implement new Items/Entities

Posted by on 08 April 2013 - 11:44 AM

I think that your solution is good if it works for your game's requirements.  However I do not think it is scalable if you will add many more different "items".  Eventually, with such hierarchies, you'll end up pushing common functionalities up to parent objects which will result in a "god" parent class.  If this works for you though, I don't see the need to change it.


The way you handle and store your entities will also be based on your game's requirements.  If holding the memory for enetities in big datastructure is good enough, then there is no problem.  This will not scale well if your have massive amount of entities.  You have to think about what you do with these entities and how many you have in the game and whether the datastructure you use will be efficient enough for your needs.  If it does become a bottleneck, then you might consider using different datastructures or reorganizing things in many smaller "pools".

#5042417 Game Structure Question

Posted by on 12 March 2013 - 01:18 PM

My questions are:


- Should the EventSystem handle everything related to weather, or only change the weather and let the TileWorld class handle the rest?

- Which of the classes should contain the variable(s) related to the weather? (For Instance the weather variable is in the TileWorld, but is changed from the EventSystem)


- If I decide to let the TileWorld hold the variables, and the EventSystem only handles the logic to change events(weather), I will have to give the EventSystem a reference to the TileWorld- I've done this quite a lot in my game, is this good practice, or should I use a different approach?


I hope I've expressed myself clearly enough- Thanks for reading :-)

Why would the EventSystem handle any logic related to the weather or TileWorld? I think you need to rethink what the responsibility of your classes are.  When you say you have an EventSystem, I invision a class that only works with "event" logic.  The way I think about an event deals with timing logic.  An "event" is something that happens at a specific time.  I would create some sort of callback mecahnism so that a class can "register" events, and the EventClass would call upon a callback when it is time to trigger the event.


For example:


class EventRegister



  virtual void OnEvent(time, eventType) = 0;



class EventSystem



  void RegisterEvent(EventRegister*, time, eventType);

  void Update();



The idea is pretty simple.  A class that needs an event would derive from EventRegister and implement the OnEvent() function.  So, say your weather class needs to have an event that will switch from sun to rain.  You would include that logic in the OnEvent() function for a "sun to rain" eventType.  You would then register that event to the EventSystem by calling on its RegisterEvent(...) function and providing it with the specific time at which the event should happen and the event type.  The EventSystem should be updated periodically.  In its Update() function, it would update the time, check to see if any registered EventRegister class have a pending event, and if it is time for that event, it would call upon the OnEvent(...) function. 


This would completely leave any logic not related to events out of the EventSystem.  You need to modularize your classes so that you can reduce the dependency between them.  I don't think it is ideal for TileWorld to have anything related to weather as well.


Also to touch on your last point, the EventSystem should never have references to specific realization of objects.  This is why a base class is used to keep things generic as demonstrated above with the EventRegister class.

#5042411 What tools do programmers make to help game designers, artist and programmers?

Posted by on 12 March 2013 - 01:01 PM



Level Designers/Editors are one tool/group of tools that programmers make.

Is the editor suppose to do this:

1) First make the map in the editor

2) Once map is done, program will generate a code in Java based on what the map looked like in the editor.

3) Programmer can export the Java code of the map created by the artist so programmer can add the code of the map

into their program.

Almost certainly not. The editor would in all likelihood spit out a file (or set of files). The game would read the generated files and perform actions depending on what was in files.

can the editor generate a file that contains a set of integers that represent game object data. Each integer corresponds with a different game objects like: stone, grass, trees, flowers, wood. Is that the prefer way for what the editor should perform?


In the end, your tool will be tailored to your engine and to the purpose you are trying to accomplish.  If your game engine has a mechanism to differentiate game objects by some sort of ids, then yes, perhaps storing objects as ids in your input file would be the way to go.  Honestly it all depends on the situation, what you are trying to do, and how your game does so.


In my experience, a tool such as a scene or level editor would probably use the same "engine" as the game.  Its job is to make the creation of entities more convenient than hard coding everything.  By having the tool use the actual engine, you get to see how things will pan out in the actual game as you are creating your level.  The only difference with the actual game is that the tool spits out a file and your game reads that file as its input.  Hence, the editor would need a way to save things out in a convenient format, and your game would need to parse that file to reproduce the entities.  The tool exports, and the game imports.


Another example.... Artists usually create content in commercial applications such as Photoshop (for textures) and 3ds max (for modeling).  The problem is that rendering your asset in 3ds max will not look the same as in your game.  An artist has no idea what his/her creation will look like until the work that was created can be rendered by the game's rendering pipeline.  A tool, using the game rendering pipeline, can be created for artists to check and tweak their creation.  Within the tool, lighting settings can be modified.  The textures and materials could be tweaked. Things will be modified until the artist is content with the results, at which point things can be exported into a format that the actual game will know about and can import in.


Similar tools can be created to facilitate content creations related to other fields... say sound for example.  A sound engineer will work on creating sound in a software he/she is familiar with.  But in the end, the results must be checked with the actual game's sound engine.  A tool could be created for that as well within which sound settings could be modified until the sound engineer is satisfied and the results match what he invisioned in the first place.


What I'm trying to get at is that there is no real general ideal when it comes to tool creation.  You must first analyze workflow problems within your project, see how you can facilitate it, and create a tool tailored for it.

#4989359 Cascading shadow maps - best approach to learn

Posted by on 11 October 2012 - 10:10 PM

The DX11 sample is complicated, but its technical article was very well written (IMO).

It really helped me understand how the technique works.

#4971954 Rendering 3D Models & Vertex Normals

Posted by on 21 August 2012 - 01:52 PM

Ah sorry, I didn't understand the question very well, haha. Posted Image

Generally you'd pass the normal per vertex in your input layout. If you only have access to the face normals, then you'd want the average normal of all faces that the vertex is apart of.

This. The Wavefront .obj normals are usually not suited for direct transfer. You'll have to do some pre-work and create a buffer of per-vertex normals. As a matter of fact, I always export my models to a .obj format WITHOUT normals. I pre-compute the normals myself at load time (though that's a bit inefficient for high poly count models).

Anyways, here is an example of how to do this:

Basically you want to get the 3 vertices that make up a face.
Get the 2 perpendicular vectors and cross them to get a normal.
Accumulate that normal for the faces' vertices.
Do that for all faces and in the end you will average by dividing the amount of times you've accumulated for that specific vertex. That number should be equal to the amount of faces that use that vertex.

There are other fancier ways to calculate normals (such as adding weights). But a simple averaging should get you started properly.

#4971517 What was your path?

Posted by on 20 August 2012 - 10:24 AM

My biggest growth as a C++ programmer happened after 6 months or so at my first job after graduating. I work as a graphics programmer, and upon starting, I had never worked on a large project or with a team. Being around other programmers and tackling large scale projects and problems really made me better. Sharing knowledge with others and getting a lot of practice in making clean code that works has been a huge factor in my growth. I feel more at ease programming and I rarely ever struggle to understand other's code anymore. Practice is key though. As with everything, you need to get out of your comfort zone and practice to expend your knowledge. I've worked with a lot of things I knew nothing about from networking to doing Linux IT work. I feel that these things made me a better programmer as well.

#4971505 Game Engine Programming

Posted by on 20 August 2012 - 10:07 AM

It takes an awfully long time just to get a basic framework that's reliable, consistent, and usable for simple demos. I have been doing work on my engine for around a year now, programming during my free time. It has just recently started to become decent enough to get some demo apps out of it. I have been focusing mostly on the 3d renderer so far. You need to make sure that your core architecture is solid and that it allows for simple and flexible expansion. Make sure to keep track of documentation, especially if you are working alone. This is one thing I regret a lot. Most of the time I add new features, I need to look over old code and try to remember how it works. I have not documented my code much and it is starting to bite me in the ass.

#4969878 Do You Have Any Favorite Computer Graphics Books?

Posted by on 15 August 2012 - 11:19 AM

When I started learning Dx11, I picked up "Introduction to 3D Game Programming with DirectX 11" by Frank Luna.

I've never read his previous work, but compared to any other material related to the DirectX API, it is by far the best book I've purchased. His demo examples are awesome and they build on top of each other using a simple and elegant framework.

Also, I've purchased "GPU Pro 2" by Wolfgang F. Engel since he was my professor for my GPU Programming course.
http://www.amazon.co...words=gpu pro 2

It's been useful into helping me learn the different techniques and usages of shaders to create advanced effects. It has a lot of cutting edge techniques related to the advances that are happening in the real time rendering field.

As far as OpenGL specific books, I'm not too sure. I know the "red" and "blue" books are must have guides though. Everyone recommends those.

#4967890 Why normalize it?

Posted by on 09 August 2012 - 02:00 PM

and it becomes a unit directional vector {1, 1, 1}

Sorry to be nitpicky but that should be {1/sqrt(3), 1/sqrt(3), 1/sqrt(3)} Posted Image

What a silly mistake. Thank you for catching that.
Let's write it out so we don't confuse OP.
if V = [5,5,5], its length = sqrt(25+25+25) = sqrt(75)
Normalized(V) = [5/sqrt(75), 5/sqrt(75), 5/sqrt(75)] = [1/sqrt(3), 1/sqrt(3), 1/sqrt(3)]

But at spotlight at the dot product L.dir is not normalized...?! float s = pow(max(dot(-lightVec, L.dir), 0.0f), L.spotPower);
Also on ParallelLight too: float diffuseFactor = dot(lightVec, v.normal); as you can see there lightVec is not normalized.
I don't understand....

L.dir is a member of the light. It is set in the C++ side, and it must be normalized there. So the shader assumes it already is normalized (which it should be anyways).

Again, if you want proper cos angle out the dot product, both vectors must be normalized. In your shader, it is assumed that the light direction is already normalized.

#4966814 How do you suppose a map like this is rendered?

Posted by on 06 August 2012 - 03:10 PM

Simplest way? Yes, a model. Basically a bunch of sub-divided planes (representing each country) with some sort of height-map for elevation. If each sub-divided plane has its own material, you could change it at will during run-time.

#4966799 NPC dialogues : file or script?

Posted by on 06 August 2012 - 02:33 PM

Yes, i mean Lua scripting for example (integrating with java/c++). The dialogue is always the same, the only "logic" operation is for the quests that NPC could give to the player: npc have to know all the completed quests for choosing which quest he can offer to the player!

It could still be done without a script but it will greatly diminish flexibility. It'll also make it much harder to expand of tweak in the future. But if the behavior is set (which it looks like it is at the moment), I would do it the easy way first, and that would be with a static file, handling the set logic in code.

#4966722 NPC dialogues : file or script?

Posted by on 06 August 2012 - 11:14 AM

Depends. If the dialogue is determined upon some previous logic or if the dialogue results in some arbitrary logic, then you would probably need to call some code within your project. Thus a script would probably be better.
On the other hand, if the dialogue is premeditated and always the same depending on some set actions, then a static file would be better.

But as ApochPiQ mentioned, the way you mention "script" is a bit different than what I'm thinking of. When I think of scripting, I think of LUA being integrated with a C++ project for example. A script would of course work, but in your case, I believe a standard XML file will suffice.

#4965974 What are the near and far plane used for?

Posted by on 03 August 2012 - 04:41 PM

Well... you need a near and far plane to represent your viewing frustum.
Using the frustum, the GPU will reject pixels outside the frustum (clipping / frustum culling).

OpenGL article on Projection Matrix:

And here is a little more advanced article about the near/far planes affecting depth buffer precision:

But in simple terms (without geometry stuff), the near plane represents your viewing window. You look through that near plane to see the 3d world. Anything behind that plane (going towards you the user) will be clipped and invisible. The far plane represents the end bound of what you can see. Anything behind it (going towards your monitor) will be clipped. With these two planes you can create a frustum by adding top, left, right, and bottom planes to create a "box" called a frustum. Anything you see in the world will be inside that box, anything outside it will be clipped.

Now, if the near and far planes are the same size, you'll have an orthogonal projection where far objects appear the same size as really close objects. If your far plane is larger than the near plane, this will create a perspective projection. Similarly to the real world, far objects will appear smaller than if they were closer to the near plane.