soc-2013-bge Feedback Thread

This post is a means for me and the community to communicate about my Google Summer of Code project. The accepted proposal can be found here:

I will be starting with an integrated discrete distance based level of detail (LoD) system, and then transitioning into a bug fixing/small feature phase. For this later part of the project I am looking for 3-4 features that the community would like to see added to the game engine. In this thread I would like to generate and discuss those ideas. The ideas will be collected at a later time and discussed with other BGE developers to determine if they will be a fit for this project.

The kind of ideas I am looking for are ones that match the following criteria:

  • can be implemented in about a week
  • will impact a large amount of users.

List of current Ideas:

  • Better control of V-sync
  • Options for non-linked real time duplicates
  • Logic Brick UI improvments (comments, color coding, properties for values)
  • Better control of material properties during runtime
  • FoV setting in Python API
  • Procedural textures and displace modifier
  • Better material support with Bullet
  • Add Xray support for screen rays
  • Camera function to convert screen positions to world positions (with provided depth value)
  • Game launcher
  • Sun shadow improvements
  • Better support for existing mapping options
  • Cleanup/improve material shadow options
  • Point light shadows
  • Python collision API
  • Python Sensor and Actuator
  • VideoTexture objects from data instead of file

For the LoD system, I will be looking for feedback to make the feature as usable as possible. My current plan is to attach LoD levels to the base object (LoD 0 / most detailed object) with a distance value. These other LoD levels will be other Blender Objects that exist in the scene. I will be creating a UI mockup in the next couple days to post here.

Kupo - Thank you for the LOD system :smiley:

Can we have a few logic bricks ?

(Torque to target), and (apply force to target (with setLinVel 0.0.0 @ each step)) as logic bricks?

So I can use Ragdoll walking physics with less Python?

I am not sure if this meets the second criteria(will impact a large amount of users), but if other people express a need for these kinds of logic bricks, I will add them to the list.

Thank you for your response.


Torque To Align Axis X to Target Every 1 frame +

Apply force 20,0,50 every 15 frames

= jumping critters ai easily

Apply Force To Target Everything in a collision check around player aimed at player… Player is…


Apply Force To target - > “Elevators” “escalators” “MONSTERS” RIGS

AI - Path leaders

Using A* TORQUE TRACK TO + Applyforce(go forward) +Random force+ = flying ai’s

Basically any “physical action sequence” can be done using the bricks

I have python for them

Do you need it to make them?

Hi Kupoman!
Great to see this thread here!! I will definately follow your progress!

Some Ideas/Thoughts. Could it be possible to generate those lod objects in runtime? The new decimate modifier preserves uv’s.
Those lod objects could be created once when they are needed and then stored during the session, so they won’t be recreated over and over again.

A small feature I would like to have for your second period is v-sync. At the moment we have to enable v-sync via the graphics card! It would be great if the blenderplayer gets a new parameter where v-sync can be enabled from the game and not from the graphics card. I think this will impact any user! And we don’t have to worry that people need to enable it from their cards! I think this a simple but nice polishing!

At this point, I am not looking into automatic LoD generation as I want to keep development time on the LoD system short in order to devote more time to bug fixing (the tracker has gotten out of control). If I get done with the basic LoD system quick enough I may consider some form of automatic generation as this would improve usability. Another possibility is to implement this feature as one of the user requested features later in the project.

I agree on better v-sync controls being useful as I am tired of turning it off in my driver all the time. It has been added to the list as a candidate. Thank you for your input.

blueprintrandom: Like I said, if more users see it as useful, I will add it to the list. Also, could you please add some structure to your posts? Such as putting code/pseudo-code into code brackets, enumerating examples, etc.

How about realtime object creation for mesh editing? I think everyone will like the option to duplicate objects (not linked) in order to deform the mesh, change textures, …

Another thing I would personally like is built-in shaders for realtime reflection, like this. It would be nice to just add a new texture to a material and set it to realtime reflection.

Great we all can profit by your projects, whatever you might choose to work on, Kupoman!

Oh, man, I can’t believe it! I had v-sync enabled all that time. Now I’ve disabled it, I don’t see any sudden increase in the Rasterizer Profile. I’m all for the proposal of ndee.

Not sure if I would have the time for creating an API for mesh creation, but I could at least look into adding an optional argument to addObject so that the duplicate is not linked. As well as a similar option on the actuator.

As for the reflection, this looks like it will only work for planes. I will talk to Martins to see if he had any clever planes for working around this limitation though. What kind of user experience where you interested in here? In other words, step by step, how do you envision using the feature?

Will there be optimization on the 2d filters, adding a glow filter can make the game drop frames?

That would be super!

I think I’ve also seen some examples with reflection on spheres, I think, but maybe it’s a little farfetched of me to want this to be integretated more. If I would know more about shaders I probably wouldn’t have this desire. But if I may, I would imagine it to be like the Reflection option in the Mapping Coordinate in Textures. Except the Image being mapped wouldn’t be loaded externally but rendered with the Martins method.

I apologize if it sounds like I don’t know what I’m talking about. In fact, I don’t know so much about how shaders work in relation to textures.

I am not sure what to do to further optimize 2D filters. I have tried removing API calls and using frame buffer objects, but this did not seem to improve performance on modern hardware significantly. This may be something I look into again when I resume work on Harmony.

Thank you for your feedback.

How about integrating some rudimentary commenting system into the logic bricks with a tooltip that shows what the logic brick does when hovering about an info “i” button like in this mockup:

Okay, hope you don’t mind, but here is yet another one:

Right now, to set an object to ghost in game, you would have to replace the object or there’s the workaround to use the ghost parameter in setParent(). I think the bge dies for an attribute KX_GameObject.ghost (Type: boolean).

and color coding of node lines, (have a color panel selctor -Select by color = select by group

I want to spend my 1000th post in an upbeat way, and what I would love is for a parenting option where within a compound mesh, childrens collision meshes are treated as being separate (so collisions with children are registered, and not just ray hits).

Thank you for all your hard work!

I see, thanks for the answer. What about optimizing the alpha mapping, that will have a lot of beneficial to everyone. Like adding decals to add more dirt to the ground or speedup of the foliage?

How about a game property that stores a reference to another object in the scene? Similar to the string/float/int/timer properties.
I imagine this would be very useful for logic brick based games (you could have an “enemy object” property, and track to/shoot at this object, but change it as need be)
This could also be useful for setting up complex relationships among game objects, especially if the objects are in a linked group.
I’m not sure this idea falls under criteria 1 though.

What about borrowing some of the code for the decimate modifier in order to help with the new LOD system, it already might have a lot of the code needed for detail reduction since it preserves UV’s and materials, and all that would needed is some touch up to avoid artifacts, the addition of distance checks to control the amount of decimation, and a value to define the maximum amount of decimation allowed.

To go even further, I once heard of a proposal to use the video texture module to replace the LOD objects with imposters once they are beyond a certain distance, but taming the GE tracker would probably take precedence over that.

What a great surprise! Thanks Moguri! So no proposal there for you, Kupoman.