soc-2013-bge Feedback Thread

Not sure the difficulty of it but it doesn’t seem like it would be to hard to add is an extra python function so we can change the field of view of cameras.

At the moment we have access to a lens python function however to get a certain fov we have to input a value of about 13.3 to get an fov of 100 rather than just inputting 100 with an fov function.

It would clean up menus and allow other users playing an exe to go into a script file and see that’s the fov and not have to convert lens millimeters to there desired field of view.

Also, when it comes to simple features at least, I would at least like to have Python access to some of the various material properties in GLSL mode (that and support for their respective F-curves).

Since the GLSL code to allow this is more or less already there, I think there’s a chance that this could be seen as a small project.

A bit offtopic :That’s just really annoying ,these 2d filters just won’t give up…seems like they just don’t want to move faster .

A small question : can something be done to improve the performance on the video texture ? It’s quite a neat feature and many people use it ,but it’s a bit slow .

Hey Kupoman,
I’m not sure if you tried this to speed up postprocessing stuff: In Other engines the render targets are defined at lower resolution e.g. width and hight divided by an factor. Intensive filters like bloom with a lot of looping will have drastically amount of performance increase.

The other thing is your GSOC project. The Code from my former attempt, implementing a LOD System is updated to newest blender source revision. HG1 has created a patch from it. If you are interested you can take a look. It seems that you proposal will do the exact same thing. (lod caluclations after culling, mesh level replacement)

greetings, moerdn

I know of somthing simple that would make my life much easier,

Have the “Ray” sensor have another property called “HitMat”.

So like a
target = cont.hitOb
targetMat = cont.hitMat

???

Wow, lots of feedback. Thanks everyone. I think I gathered most of the ideas into the first post. For the summer of code project I do not want to do too much with 2D filters as this would start mixing my two branches (SoC and Harmony), and I would like to keep them separate. If I have time I could take another look at 2D filters in Harmony.

Moerdn: Glad to hear from you again. I had no idea what state your LoD work was in, I will definitely be looking at it. If it is mostly good to go, then I may use it. With the time saved I could look into more advanced features for the LoD, or focus more time on the other parts of the project (bug fixing and polishing).

BluePrintRandom: The Ray sensor already has a material option, so I am not sure what you are asking for.

The texture code of the Blender Internal renderer should be separated out into its own library so the BGE can link against it. Similar results could also be accomplished by linking against BI, but that’s probably too much extra code and seems kludgey. The benefits of having access to this texture code is that the displace modifier will actually work in the Blenderplayer, which makes height maps easier to use, and it also opens up the possibility of having the procedural textures work in the BGE and the viewport.

On this, my request is not going to be the same as BPR’s but it deals with the sensors and materials.

As far as I know, the collision, radar, and ray sensors have never had an option to detect the presence of a material on a per-face basis, it would always return positive for any mesh that contained the material, even if it was just on one face at the far end of the mode.

The proposal would be a slightly more advanced option to detect just the faces with the material assigned to it instead of the entire object, so for things like large interior scenes, the collision sensor for example could go positive when it detects a tile material, but not a carpet material. This will help differentiate it a little from the ‘property’ option which would obviously still be for the whole object.

What would also be nice is to remove the longstanding limitation of the object using only the first material for its physics properties (friction, restitution, ect…), so in a racing game for instance, your car will encounter a much higher friction if it ever goes off the road providing it’s all a part of the same mesh.

More code being shared to the benefit of BGE users would always be a nice thing to have, and it also fits more or less with Ton’s eventual vision as well (though in a way that gives greater control to those who love using the BGE and would like to see massive improvement).

I say to Kupoman, go for it :slight_smile:

Just like what ace said,

I use castRay() to this now, but it’s pain in the butt

Having the ray sensor have a property “hitmat” is not rocket science that it would make it more accessable

So what would it hurt?

have a check box?

Things i want in BGE : (priority wise )

  1. Level of Detail
  2. Viewport Movement in_game
  3. improve BUMP mapping

Well, am I the only one who sees very nearly nothing missing in BGE at the moment? The only limits I’m hitting at the moment aren’t performance wise, API wise or anything else. The only limit I’m hitting is my own creativity (and the amount of time I can spend on blender).

Simple stuff is simple, and complex stuff is possible. Who needs more than that?

Here’s my wish list:

  • Allow property names to be entered into logic brick value slots. (Would have been useful back when I used bricks)

Besides Mesh LODs, it is useful to have a way to specify Material LODs too. Material LODs might be achievable if you can customize the Material for the Mesh used in each level, but sometimes it is useful to have the Material level change while using the same Mesh level. Also, different metrics for when to change the level are useful. Another rendering engine offers an option to use distance or screen size.

About the 2D filters: I use them for bloom and I always downsample before blurring. I try to keep the number of samples in my blur shaders to a minimum (Gaussian). If you do not downsample, you can expect bad performance because you are moving a lot memory around when shaders have multiple source samples per destination pixel. Is it easy to specify render target sizes?

Thanks for the great work.

Here’s my wish list:

  • Allow property names to be entered into logic brick value slots. (Would have been useful back when I used bricks)

Amen…!!!

like

Obj -Cube
Properties
X
Y
Z

Always--------------and----------motion Force “X”,“Y”,“Z”

Keyboard (press)--------and----------X=X+1
if X <10---------------------/

Keyboard (press)-------and------------X=X+(-1)
if X > 0 ---------------------/

without any python !!

Save and load logic brick acrossed multiple blend files.Logic brick that would automatically aline added objects edge to edge with objects you specify.It would use objects added by the add object actuator.

Hello
Instead of more “functions”, It’ll be nice to have a “usable” Logic Bricks Interface!
Bye and thank you for your effort

Awesome stuff Kupoman! Here are some suggestions:

forgive my psuedo code :stuck_out_tongue:

  • More access to physics properties for eg;
KX_GameObject.physicsType = logic.KX_PHY_RIGIDBODY
KX_GameObject.physicsType = logic.KX_PHY_NO_COLLISION
KX_GameObject.collisionBounds = logic.KX_BOUNDS_BOX
KX_GameObject.collisionBounds = logic.KX_BOUNDS_SPHERE
KX_GameObject.collisionGroup = logic.KX_COL_GROUP_1
KX_GameObject.collisionMask = logic.KX_COL_MASK_1
  • Method to generate a new material at runtime and change objects material for the main purposes of texture swapping without having all the objects with the same material getting their texture swapped.
  • Above may be solved with adding of unlinked game objects
  • adding xray option to KX_Camera.getScreenRay
  • adding a method that does the reverse of KX_Camera.getScreenPosition whereby you input screen positions [x,y] and a custom depth float and it returns the 3d position vector. Or at the very least a way to get the directional vector of a given point on the screen(2d space) into the scene.(maybe there is a way to calculate this already, please let me know)

Hopefully I can think of some more later.
Good luck. :wink:

Great! It will be ultra useful!

I see it similar as sdfgeoff.
The BGE has almost any feature to create a game! I would love if the focus would be more on polishing!

@Daniel,
could it be in your scope to create a BGE Launcher, that keeps blenderplayer and blendfile separate? Here is a preview of an addon I have started some time ago. At the moment I am not working on it. It also only supports windows atm.
But if you like a can provide you all sources! Here also… every user would benefit from a proper launcher! It will be easier to publish and solve GPL issues because the blendfile is not packed into the exe.

My launcher is written in python. GUI is done in wxpython. Executable is created with pyinstaller. The addon itself just copies the files in the needed directories, thats almost it.

What do other people think?

that’s a great idea! for persons that don’t know a lot of that licence issues and just want to “launch” their game to be played.

I think I would love that, or even something like “change the icon of my own game” that could be possible with hack programs but… Why?

bye bye