Irrlicht Engine

I had a quick look and found this

You may use, reproduce and modify the SDK on a non-commercial basis solely to develop a modified game (a "Mod") for Half-Life 2 or other Valve products compatible with and using the Source Engine.

http://store.steampowered.com/subscriber_agreement/

Thanks xDan, I figured as much

Christian thanks for the references, I think that we will need to make a vote for the theme choosed. But those should be game like, I mean when it's we will finish the user should be able to walk through the land.

http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=32936

We could use those as reference they were asking us nicely to use them

Thanks XDan.

I didnt found it. That's pretty clear. I don't understand why, but they've written it.

I think that we will need to make a vote for the theme choosed

Yes, Steel Style. I think it would be important, so everybody that will do art for this will have a base reference to do it. We could then create "art-packs" exclusively made for IRRlicht. (Could do theme related art-packs)

Right now the theme is RPG? . Having a clear reference on what to do would be nice. For something to look realistic (even game type), the best references need to be real or based on reality. Using stuff made for games distort that. We should stick to photos or historical diagram as much as possible. (Even for sci-fi, if we want to have a "look")

I have another question about this. Any ideas about triangle count for:

- Building (Outside view, huge (castle, skyscraper):
- Building (Outside view, small to medium):
- Characters/statues:
- Prop (big as big as a character):
- Prop (small, like a weapon):
- Prop (small, like a can):

For me, I'm ready to work on a building for this. (Inside and outside)
Thanks Mel. I've found theses ones (searched for "medieval"):



http://www.michaela-august.com/street_of_knights.jpg

Correct me if I am wrong, but isn't the art style close to the last thing we should be worried about? I think we should still be discussing ideas on increasing performance of large draw distances, shouldn't we?

For those of you who were not part of the IRC discussion the other day, I brought up an idea that would make this system and the draw distance very scaleable. My original idea was simply to use a fog that is the same color as the background, that way the drop off from what is drawn and what is not drawn is smooth. Of course, with a complicated sky box, that doesn't work very well since the skybox wouldn't be a solid color. Instead, what you can do is make the fog dynamic, and have the fog change itself to the average color of the portion of skybox that is visible in the camera, and then reduce the opacity of the far objects, so that way the solid color only partially blocks the sky box. If I remember right, that's part of what Far Cry 2 does to get it's far draw distances.

Here is a scale proposition : Thus a 65635 units squared area in 3D represents 1667 meters squared in real world
65365 is the maximum allowed by several editors for obvious 32 bits reasons.


View frustum Culling
irrlicht is good at it already. Let's assume nodes that are not in frustrum are not drawn by default : this is built-in irrlicht feature?

Detail culling
Consists not to draw objects that are too far away.
Camera Far Value and fog do it well, as you pointed out, DeM0nFiRe.

LOD
A model located pretty far away from the camera is represented on screen by only 1 pixel. However suppose this model is made of 20.000 tris, it would be a
waste. So the idea is to show the high-poly version of the model only if it is very close from the camera, otherwise draw lower poly versions of the model.
Modellers usually start by creating the high-poly version, then derive it in 4-5 models the last being the most simple shape imaginable. Polychop is a good
Max plugin for this. This method is used in most modern engines. It is really worth the treatment/polies reduction. One of these models can be used in the editor to help the level designer.

I proposed to model an object for this. It works fine, I implemented it 2 years ago for vast woods. The code is very easy since it only consists in determining the distance from the view point to the object, and show the appropriate model for the LOD level. Of course this step is performed
after frustrum culling. Just be precise about the first model to "build" because it takes time to create a model.

At some point I am sure the mipmapping LOD code from ITerrainSceneNode will help because it allows to manipulate the mesh automatically, this saves the work of 4-5 people isn't it?

Occlusion culling
is something about Z-buffer one could explain better...

Portal Culling
This is one of the important steps during the compilation of the bsp.
A room is a box. When you are in a room, you can't see the furniture in the room behind that wall, so don't draw it! Fantastic boost and extemely fast code
however there is no general implementation of portal culling because a generic solution won't reach the top performances in every case. Programmers like
code dedicated to its task and we go for performances (this includes low-end hardware?)

I implemented this method, but not on a bsp. The process consists to create cubes in the editor (an irrlicht-based editor BECAUSE irr bsp loader does not
recognize func-brushes) then the engine compares these boxes with the rest, allowing to say "yes, the player is in the re-health area, give him 100 points health", or "no, player is not in the cave, so hide the node of cave interior and disable normal-techno-parallax-bump effect from it". Portal culling is outstanding for indoor maps.

At the moment the irr bsp loader partially ignores precalculated leaves stored in the binary file. Dont get me wrong what has been done is outstanding. If I
remember right the code has the bit buffer precising if a leave can be seen by another or not. Just need to determine the PVS and it's done. Who can?
I think we could just copy the Q3 namespace, call it the Steel namespace and start from there.

Katsankat wrote: 65365 is the maximum allowed by several editors for obvious 32 bits reasons.

Looks to me like very restricted 32bits - half the dword for signedness or what

@Hybrid: No, the other 16bit are for CRC

If I understood correctly, you want to do create something like 3DMark?

@DeM0nFiRe: Premature optimization is the root of all evil

So I'd suggest, make a scene, optimize it. Add next scene

The Torque game engine used another scale for their games, if im not mistaken... 1metter = 32units.

And in Quake units, if i don't recall bad, characters were 8 units tall, that corresponded to 2.54 metters, or 100 inches. So, a measure similar to that would be a good one,

1 inch = 1 Irrlicht unit is small IMO.

16 units = 1 metter i think is more useful.

Great photos Chris!

Unreal ('98 ) has something like 64 units = 1m IIRC. Well, I don't really see the point in doing these conversions, but at least you should stick with SI Units...

What about Shadow Frustum Occlusion? SteelStyle and I were talking about it. It basically works the way shadows do, except instead of a light source you have your camera and instead of shadows, you just don't draw anything in the "shadow frustum."

Also, does Irrlicht already do View Frustum Occlusion? In my benchmarks I noticed that irrlicht ran exactly the same for 10k cube meshes whether or not the cube meshes were actually in the view frustum.

DeM0nFiRe

but isn't the art style close to the last thing we should be worried about?

Perhaps, but since this was posted in "Everything 2D/3D graphics". And this is asked for a "community project". Should be nice that we define at least a common ideas for the objects we'll put on the massive level. (At least would look nicer and would be a good thing to demo IRRlicht)

I have something that could be used RIGHT NOW for testing occlusion. My first level with the metro/Bus station. This level is not massive but have framerate problems when you turn at certain angles (facing the whole station, will have a framerate drop). Occlusion is not accounted for. Also if you want to really see the end of the underground tunnel, you'll need to increase the ZFAR value, another test for the occlusion, since you'll need to see far.

The file is a Zipped file (pk3) and the whole scene can be opened in IRRedit, that contain multiple OCCtrees for the pieces of the level.

Here is the link to it, you can use it as you wish, all artwork was created by me and you will not have copyright issues (unless someone says that using Lightwave and Gile[s] is not permitted for X reasons... ):
http://downloads.sourceforge.net/first- ... e=29407898

So you can start try some algorithms on this now an see if framerate increases.

If you guys are still ok that we do some artwork with a defined theme, I'm still here.

DeM0nFiRe wrote: Also, does Irrlicht already do View Frustum Occlusion? In my benchmarks I noticed that irrlicht ran exactly the same for 10k cube meshes whether or not the cube meshes were actually in the view frustum.

Maybe it's related to this: http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=32581

hybrid wrote:

Katsankat wrote: 65365 is the maximum allowed by several editors for obvious 32 bits reasons.

Looks to me like very restricted 32bits - half the dword for signedness or what

65k x 65k maximum map size. This makes 4,272M fields