BGE proposal - Group/Instance Properties - Discussion

Game Engine Game Engine Support and Discussion
1

Danger! Long Text!
Hi,

usually I do not post that much feature request as I’m quite happy with the Blender and the BGE.
But here is an idea that could move the development pipeline for the BGE much further. I want to use this thread to present the proposal and collect your thoughs, concerns and ideas.

Maybe this is possible as Add-On. It looks like I have to join the development path :spin:.

If you do not understand what I’m writing here, just ignore it ;).
Otherwise what do you think?

Monster

Proposal of Group/Instance Properties

Glossary:
•Group: An entity that can be assigned to objects
•Group Object: An object that is assigned to a group (green)
•Instanciating Object: Object that creates the Instance Object via Doupli Group
•Instance Object: A copy of a Group Object that is created via Doupli Group

Existing (Object) Properties:
•The existing properties are Object Properties
•They belong to the properties owner (object) only
•They can be used in Sensors, Controllers (incl. Python) and Actuators
•When instantiating a group the newly added Instance Objects and its properties are not accessible, but the Object Properties of the Instantiating Object are.

What are Group Properties?
•Group Properties belong to the objects of a group
•All objects show all Group Properties in the properties panel (marked as Group Properties)
•Group Properties appear as Reference to the same Data location (change at one object is a change on all others)
•Group Properties can be used like Object Properties.

Property GUI for Group Objects

What are Instance Properties?
•When instantiating a group - the newly added Instance Objects are not accessible, but the Object Properties of the instantiating object are.
•The Group Properties of this particular instance appear as Instance Properties of the Instantiating Object
•The Instance Properties are only shared between the Instantiating Object and the Instance Objects (not with the original Group Objects!)
•This allows the Instantiating Object to provide individual Parameters to the Instance Objects and get information back from the Instance Objects
•The Instance Object can use the Instance Properties like normal properties with one exception:
•Instance Properties can’t be added or deleted

Property Gui for Instance Objects (without the X):

Benefits
•The Instance Properties act as interface between the Instantiating Object (full access) and the Instance Objects (no access)
•It allows to create groups with complete logic setups (incl. but not restricted to Python) as Libraries.
•Individual parameters can be configured at the Instantiating Object
•For instantiating it is not necessary to know the internal implementation of a group (which is not accessible at that point anyway)
•Objects in a group/instance can share information to each other, without knowing each other.
•Objects of a group/instance can share information with the Instantiating Object.

Drawbacks
•Objects in multiple groups:
–Maybe adding the Group Properties to all Objects of both groups?
•Removing an object from a group:
–Treating as single object group ?
–Removing all Group Properties (if not used in SCA) ?
–Converting to Object Properties ?
•Duplicate property names possible when adding an object to a group:
–Removing the Object Property ?
–Auto renaming of the Object Property ?

API Extentions
KX_GameObject:
Access via dict - as with Object Properties (e.g. object[“prop”])
a)Added to getPropertyNames() [not distinguishable from Object Properties] or
b)New getGroupPropertyNames()

2

hi Monster, this thread might be of interest to you and also relates to your proposal

http://lists.blender.org/pipermail/bf-committers/2011-May/032128.html (browse next replies from http://lists.blender.org/pipermail/bf-committers/2011-May/thread.html#32128 )

3

Thanks for the links.

Haven’t followed the node system discussion that much (this mails are licence related :wink: ), but I do not expect it soon.
I’m not sure how that gets integrated into the BGE.

I’m pretty sure the SCA-logic will survive. Otherwise all the resources (tutorials, logic, Python code) we have now would be useless. That can’t be the goal of the development.

I think it makes sense to still improve it :smiley:

Monster

4

Hey Monster - can you also put out there that they should make an ‘x-ray’ feature that works via BGE?
Most modern day games don’t even go without it!
Specially if you want to make an up to date FPS where your gone doesn’t go through nearby objects :wink:

NOTE: ‘X-ray’ can be found in Display objects -> ‘X-ray’

5

<i>SCA-logic will survive.</i>

the nice feature of component approach ( and even could be experimented with basic code here https://github.com/caseman/grease ) is that code is separated from data.

that way - it is possible to write nodes from blocks with any attributes and then insert logic. That will pretty well integrate with current system and also can serve a base for your proposal - just to have a layer to keep attributes of groups and members of groups to be somehow connected.

6

But that has nothing to do with the logic changes.

Finally it will be up to me to implement that (except anyone else is interested ;)). I want to see if you can see any problems with the proposed solution. So any obstactles in the design can be removed early.

7

Is Glosar like the Prefab in Unity3D? (Assuming you’ve used Unity3D) , if you haven’t - it’s just an motherobject for all instanced objects of the motherobject. So if you change the motherobject - all instances are changed accordingly.

8

Oups wrong word. it should be: glossary

When reading again, I see it shouldn’t be possible to change the type of an instance property. This should be possible at group properties and object properties only.

9

Also, it appears that you think that instanced object properties are not accesible?
They are, just not via debug properties…

ob = scene.addObject(“Cube”,“Empty”)
ob[“var”] = “hi”

10

I’m right now trying to understand this because I have to handle it in flexicomp so apologies if I miss Your point… But I think it would be cleaner to handle it by:

  1. A callaback (much like scene.post_draw) that is called when object are added with both the original and created object as argument.

  2. One callback on every object thats called when an copy is created with that object as original.

  3. One global callback that is called every time a copy is created of any object.

  4. Callback function should be possible to register both with python and with gui (like the python controller).

This is so far the same with groups or ordinary objects. But if You want to make a ‘automagic’ group add a callback function by module that sets up the object proper when they are created. The module namespace is a perfect global namespace for the group and all it’s instances. From there we can build any data structure we need.

Callbacks is useful for allot of other stuff to so it’s a general and powerful solution. There should be a callback on end object to - both per object and globally.

11

Callbacks?

I think my proposal is not that clean as I thought.

The whole point is with that method you do not need python. It is a way to enable a user of a group instance to push paramters into the group instance (remember you can’t select the instantiated objects!).

If you instanciate you get an object (usually an empty) with doupli groups.
In the 3d view you can select the empty only (not the instance objects). You can move the empty around, the instance objects will follow the empty.

Because you can’t select the instance objects you can’t change the logic nor the properties. This is good in one way: It hides the implementation to the user. But bad in another: the user can’t influence the logic as there is no access.

What the user could do is to set up object properties at the empty. The logic at the group instances can read that properties (via Python). That is possible already.

Two problems:

  • the user does not know the properties he can set (needs external documentation/can mis-type it)
  • the instance objects do not know when these properties are changed (or they need to look at each single fram with Python = bad performance)

The proposal is to share properties between the empty and the object instances.

  • the instance objects establish these properties (as group property at the group objects)

  • the empty shows these properties in the logic window at design time
    +++ the user can see them
    +++ the user can see the default values
    +++ the user can change the values

  • the empty can use these properties logic in it’s own logic (with or without Python)
    +++ the empty’s logic can read these properties (might be updated by the instance objects)
    +++ the empty’s logic can change these properties (to setup new parameter for the instance objects)

  • the instance objects can use these properties in it’s logic too
    +++ they can establish properties sensors watching for a change (e.g. from emtpy)
    +++ they can change the values to deliver new data to the empty

12

OK. Think it got clearer. We got two possible levels of instantiating.

In blender, when creating an instance of a group. I think group properties that set to a default in the original group in a library .blend but can be changed for the individual instances of the group is sane.

In BGE, when creating an instance with scene.addObject() a callback is the logical chose. Because BGE can’t know what’s sane to do. A tree might want to hook up with a LOD and only show different of the individual object when told to - A car want to add the body, the wheels and set up the vehicle constraints.

Hmmm… The hiding of internal objects make sens in blender but not in the BGE… Damn, still don’t know how this really works. Got to experiment a little.

13

I wouldn’t allow group or instance properties on addobject. It makes no logical sense as there is no group and no instance.

The instanciation is reall simple:

your “template” consists of group objects = normal objects assigned to a group e.g. “MyGroup”.

When instanciating you get:

  • an empty with doupli group activated (usually named with the group name “MyGroup.001”), douple group references the group “MyGroup”
  • a copy of all group objects which are now instance objects.
  • you can only select the empty

alternative instanciating:

  • select any object
  • enable doupli group manually, enter your group as reference “MyGroup”

the group does not need to be in the same scene. It should be present in the file as data block or as link to another file. This makes it perfect to act as library. Multiple blend files (e.g. Levels). can share the same groups (libraries).

when running the BGE you get the same objects too, with a difference:

  • the instanciating object does not know the instanciated objects and vice versa. (Moerdn made a fic for that !)
14

Made a quick hack for that so you can see this useful feature in action:

greetings,
moerdn