Here are the latest environment shots from the island and the lava levels, with shadow maps(shadows+ao), and props all around like grass that’s the wrong color green, flowers, mushrooms, logs, etc.. There are things that still need to be finished, like fx(note the lava platforms are supported now!), water, lighting, sky, and animated WATER. Make some noise if you’d like to see Brecht add a decent alternative to animation maps for animated textures! No promises, but he’s thinking about it.

I’ll finish up with these levels this weekend and then next week is a big week. Everything starts getting wrapped up into a complete package. Pablo starts working on documentation, Campbell is finishing up with enemy AI, and now we’ve even got pesky rats running around! Moraes Junior (aka mangojambo) has been making brilliant animations and will continue with this too. Next week we’ll be posting a video or two showing some special effects and gameplay.

73 Responses to “Environment update, shadow maps!”
  1. Francisco Ortiz says:

    @Carsten: yes please write tutorials! Your tutorials for BGE are awesome ๐Ÿ™‚ (Gamekit).

    Beautiful screen shots. My noise goes for documentation…Instead of graphics we would like to know more facts about Brecht’s life, since the topic has a very weak cover inside this blog. Please include some extras about his childhood/kindergarten, that would be great! : ))

  2. Very nice screen shots ๐Ÿ˜‰ great work!

  3. This is looking really nice. I can tell that the lava level has gotten a lot more love since the last time we saw it. Bravo. Also, to Brecht, good luck. I think there’s enough NOISE around here to warrant another sleepless night for you. ๐Ÿ™‚

  4. Inko I. A. says:

    Eh! I’m really impressed with those screenshots!!

    Posting on, posting on twitter, forums…

  5. nowherebrain says:

    Looking good, never thought BGE would shine like this.

    1) animatable U.V.’s
    2) level loading(of course)

  6. cyberdigitus says:

    Great optimisations, i get 35fps, just glsl without any options, but when i turn on the tree layer, physics jump to 85% from 7% with a framerate of 2fps.

  7. @ cyberdigitus, yeah dont turn on the trees!, or if you still want to play with trees in game, convert them to real (select all the trees/emptys, and press Ctrl+Shift+A, if i remember correctly..)

    problem solved! :), the slowdown is caused by a bug (in instances) that is being worked on.

  8. I refuse to make noise, but I’ll leave this comment here stating that I would very much enjoy liquid physics. There has to be some reason I bought a 64 bit dual core 2.2 GHz CPU with 4 MB of L2 and an 800 MHz FSB, right? ..and the GeForce 8400m gs, too.

    Make my hardware gasp for air, so I’ll have peace of mind that when I buy something even more powerful, it won’t just go to waste because I’m a FOSS purist.

  9. Beautiful! BGE has come a long long way. Excellent work all! I would love to see the same kinds of effects available in AAA title engines available in our lowly BGE. How can we keep this pace of development up? What’s the next project? I’m sure that the BGE community will be happy to contribute our $$ to this goal, if the outcomes are well defined.

    I am EXCITED!

    Congratulations on work well done!

    have a day.yad

  10. Yea as amazing as it is and proud as I am of Apricot. Its getting so near the end of the project, that the fanboy in me can’t help but wonder what the next project is gonna be. What are we gonna have Plum? Nectarine? Apple? Pomegrante? Maybe Lemon or Lime? haha ok. Well, I’m excited enough to see how Yo Frankie! turns out.

    Can’t wait to get Yo Frankie! in the mail. You guys have done great work!

  11. wow the game start really looking like a professionnal one ๐Ÿ™‚ congratulations !

    i have one question:
    is occlusion culling now supported? or is there any development planned for this?
    because it seems to be an interesting missing feature of the BGE.


  12. Helo Apricot team!
    I have a little idea: Object “off distance” feature!
    This is a very simple trick to speed up the game engine render!
    So if we can set a distance value for every object and in game engine render the object dont render after this distance we will get a speed up of the render.
    No need to calculate the distances of every object in every frame! This calculating can be share among frames or we can use other “sharing” trick.
    Sorry for my bad english, I hope you understand that I wrote. ๐Ÿ™‚

  13. endi, that was planned, but I don’t think there will be time to add it during this project. It’ll get in there one day.

  14. Deloince jp says:

    endi, blengine,
    you talk about the LOD,
    level of detail?

  15. @Deloince jp:
    I think it’s more like a “distance cull” thing they’re talking about. Instead of replacing the object with a simpler mesh, they’ll just turn the mesh “off” once it’s farther than a specified distance.

    @endi: Yeah, I think if they combined that with LOD support, Blender would really get a nice frame rate boost!!

  16. Strange, but many big games dont use LODs only for characters like things (so that uses bones).

    Nowadays the videocards can render many polygons without slowing down. The biggest speed problem is the number of render batches. So many big games uses only object distance off methods without geometry LODing.

  17. @endi:
    Yeah, that’s true. If I understand right, I think your saying that modern hardware has become so fast that the small amount of gain from LOD support has become insignificant, which in most cases I would agree. However, there are still the people, like me, that don’t have modern hardware and need all the effeciency we can get:)

  18. Endi (post 66), DanZMan (post 67),

    Currently, the use of LOD is inevitable even with graphics cards latest, over the years, the games are designed with an exponential complexity in the use of the number of polygons and grandeur of textures. The dream is not done, quantum computers n’existes not today, if now the graphics card can make many polygons without slowing down, tomorrow will be different!

    By the way, hello to all the team apricot and all persons present here!

  19. Deloinc JP,
    Ok, I repeat that I wrote:

    Nowadays many of the big games dont uses LODs. These games uses LODs only for skinned-boned models.
    This is fact. You can debate with facts, but I have no time for this, so, bye.

  20. Endi,
    I do not debate with facts so you n’ayer not have time to respond,
    I try to understand the English translations french, I do
    not a champion of the English language and sense are not
    adequate return.
    When your politeness (This is fact. You can debate with facts,
    but I have no time for this, so, bye.) keep it, thank you!

  21. and what about occlusion culling ? ๐Ÿ™‚ (post 61)

    lod can be easily replaced with a simple python script (but less effective than a hard coded one of course) whereas occlusion culling is really complex to code and can open the path to large complex levels

    tell me if im wrong ๐Ÿ˜‰

  22. Yes, the occlusion systems are complex and hard to code.
    So if we need a very simple “lod” system, the distance-off thing is a good choice: simple to code and effective.

  23. Well, LOD systems are fairly easy to code as well, so I still think a combination of the two would be neat. Distance off is good, but the thing is, when there are lots of objects, such as trees, the computer is forced to process all the polys of all the trees from the front to the back, and so you will have to set your “cut-off” distance to a smaller value to enable the computer to handle the scene. This results in a shorter view distance than in an LOD implemenation which will dramatically reduce the number of render batches needed for the scene and allow for a farther “cut-off”(view) distance.

    Anyway, either way, I’m very impressed with the changes done, and any type of occlusion/cut-off system would be fine with me:)