I would recommend using vertex arrays or vertex buffer objects regardless as display lists can be hard to manage and vertex arrays support dynamic geometry.

Why this recommendation?

Displaylists are faster then buffers since the data is stored on the video card, and not re-sent on every frame.

A buffer is faster then sending each triangle via several OpenGL call, but cards which don't support display lists most likely aren't fast enough that buffers would make much of a difference.

Here is a question, which is off topic of textures:

What is the performance hit of the act of compiling a display list. Would it make sense to compile objects when they enter the view frustrum, and free the compiled list when the objects leave the frustrum. Only to have to re-compile them again later.

They are clearly using shadow maps, and the sample bias is giving the effect of soft edges.

When your playing the game you have a squad of troopers, and each trooper casts a shadow.

It appears that part of the level information contains the location of where shadows will come from. For example, one room may come from the corner, while the hall way connecting the room has it from above. This sometimes looks good, while other times it doesn't match the levels lighting.

For each trooper they render a small shadow map, and only use this map overtop of the background (i.e. the floors and walls).

So if other animated objects (i.e. bad guys) walk between the trooper and the light source. Then the shadows don't appear on them. The shadows are also not self-shadowing.

They also gave the shadows on the floors a fall off that blends them into the background. This looks really nice, and helps prevent the shadows from contrasting with the levels lighting.

Still, they get very good frame rate performance, and in the context of a video game people don't notice the small errors.

Except for one part when the shadows appear on the wall, with the feet of the troopers about 2 feet off the ground. OOPS!

If you are going to develop JOGL for Java 5 then I'd recommend you wait. You can not run Java 5 applications on the Mac. There is only support for JDK 1.4.2, and I don't know of a timeline for when Apple will come out with support for Java 5.

You asked the question of how to create addictive behavior in players, and then talk about difficulty in game play or level design. When you increase or decrease difficulty of game play you are affecting the players sense of goal achievement. For example; You may have a game designed were a player must reach the end of a maze, and as they approach the end of the maze an increase in traps makes this goal more difficult.

Creating realistic and obtainable goals for the player is a key to giving them a sense of purpose for playing the game. Meanwhile, creating difficulty in the game directly affects the player&#8217;s motivation to continue playing. People like to work towards realistic but challenging goals in life, and in play. If the goals in the game are too easy, then the player will loose interest, and if those goals are impossible then the player will quit. So a challenging and realistic goal is the key to motivating a player to continue playing.

To make a video game ADDICTIVE one should try the laws of operant condition from psychology. You should create a pairing of a conditioned stimulus with an unconditioned response.

For example; when you play on-line Poker you have an unconditioned response of an increased heart rate, and emotional arousal with the presentation of a reward (i.e. the pot of money). At the time that the player wins the hand the video game can present an auditory and visual queue that marks a conditioned stimulus. Now as the player plays Poker they develop a conditioned response of excitement when ever similar auditory or visual queues are presented.

So, to create an affective and addictive video game the use of auditory/visual stimulus is very important. You should present a stimulus prior to the presentation of a reward. For example; you could play same theme music just before a every level boss. You could flash eye popping large text on the screen when the player picks up a power up or scores points and this will help present to the players that a reward has been given for their efforts to play the game.

Pairing this conditioned stimulus with rewards in the game is the key to making it a successfully addictive video game. The better you can pair an unconditioned response with a conditioned stimulus will result in a stronger addiction for the player.

I think your talking about creating billboards by rendering an object to a texture, and then replacing the far away high mesh object with a simple billboard.

This is often done when visualizing a large city. You render the far away buildings to a texture, and replace them with a billboard. As the person drives down a road and gets closer to the billboards, then they are replaced with meshs, and new far away buildings are introduced to the scene.

Clouds are normally done with a sky box. You render the sky box as a background in your scene, and it gives the impression of clouds in the sky.

If you want animated clouds, then you add a textured cloud plane that has drifting clouds (i.e. animate the UV coords). This is blended with the sky box.

I'm looking for information on how glass wall effects are done in video games that make the glass look bumpy or textured.

I've seen special effects done with glass in both HalfLife 2, and Rainbow Six on the XBox.

In both cases there is a glass wall which you the player can walk up to, and see threw. You can see other characters behind the glass wall in great detail, except that the glass is bumpy like glass bricks or an office door.

How is this effect done?

From what I can tell. It sure does look like they render the scene, and then the glass is a second pass. They shader appears to be sampling the image buffer from the first pass.

Is it possible to sample the buffer from a shader? I thought this couldn't be done.

Our 3D product contains over 10,000 models, and is already deployed across several customers.

So I'm stuck with the library of models. I am writting a new 3D engine to replace an older out dated one.

Also, if we get a contract from a new customer for example: ABC Toys and they provide 5,000 models in DXF format. Then we have to do the best with that we have. I can't go to the customer and say "our shadows don't work because your models aren't 2-manifold".

Then, on the other hand I have a boss who says "We need better shadows our scenes are full of artifacts".

What am I going to do???

I need a strong shadow solution for non-2-manifold models.

I will have to use the orginal zpass approach to shadow volumes, and see if I can figure out if the camera is inside the volume of an object, and disable the shadows for that object. Still the NeHe tutorial example introduces a few other problems.

I have noticed (with a little pain) that the shadow volume demo that comes with JOGL doesn't work with flat planes, or meshs with deleted triangles making holes in them.

A mesh could be said to have a hole if it has a face with an edge that is not shared by another face.

The demo appears to only work with objects that are solid objects, where as a plane of two triangles doesn't cast a correct shadow.

I think this is related to the methods for drawing the end caps of the shadow volume. Since a flat plane will only have one side facing the light source, then it doesn't have both caps on the shadow volume.

After doing all the work of including the shadow volume rendering in my engine. I find that I can't use it.

I'm thinking I will have to use NeHe's shadow solution, which doesn't work if the camera moves inside the shadow volume. Where as the JOGL demo works in this case.

Can anyone confirm my problem who understands what I might be talking about?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org