[Bf-committers] my GSOC project idea

[Mitchell Stokes]

> *Idea 1 : Improvement of Game Engine Python API*
>
> 1.providing syntaxes similar to  these -
>
>    a. *scene.meshes["meshName"]*
>
>    b. *meshI.material.textures["myTexVar"] = loadedTexture  *
>
>    this is for *KX_MeshProxy* class.Like textures the options for setting
> these properties
>    can also be included.
>
>
>   -     The Blender material.
>   -     The Tile properties
>   -     The face properties - (From the "Texture Face" panel)
>   -     Transparency & z sorting
>   -     Light layer
>   -     Polygon shape (triangle/quad)
>
>
>    so In general the syntax may be
>    mesh.material.propertyName["Var"] = propertyValue
>
>    c. * scene.object_instance("name")  *

I don't quite get what you're trying to show with the examples. Maybe
an example of what the BGE is currently doing and how you want to
change it?

> 2. a collisionList may be useful.
> collisionList = references of those objects colliding with the player

That definitely could be useful.

> 3.Removing some limitations:
>
>
>   -    access scales for the orthographic camera
>   -    turn slow parent on and off
>   -    test getVertex() and solve if there is some problems with it.
>   -    adding play/pause sound actuator

Isn't there already an actuator for sound? There isn't a Python API
for sound yet though. :)

> 4.Some genereric methods for path finding/searching/other AI:
>
> there should be a standard for a path.It be a graph of vertices (edges
> between them).
> So the generic methods may be -
>
>
>   -  *  graph = makeGraph(pathMesh)*
>   -  *  graph.node[index].adjacentNodes()*   // The function will
>   precalculate the adjacency lists of nodes and return them during function
>   call
>   -  *  graph.node[index].cost(destNode)*    // This will return the cost
>   between index node and dest node.they can be calculate by the distances
>   between the nodes.
>   -   There may be support for some built in heuristics function also.

This could be handy. However, you have to make sure you don't clutter things up.

> 5.developing an easy way to access external programs(e.g. Browser,irc chat
> app)

I don't see a huge need for this, and it can probably already be done
with things like pipes and sockets.

> *Idea 2 : Improved DDS support for Blender and BGE*
>
> BGE currently support dds.But not really takes any advantage of its format.
> it has some problems also (e.g.
> https://projects.blender.org/tracker/index.php?func=detail&aid=18653&group_id=9&atid=306).
>
> So the scope of the project may be -
>
>
>   1. Fix  bug of current dds support
>   2. make BGE support for proper dds compression.
>   3. UV/Image Editor operator to convert image as .DDS
>   4. Option to convert internal textures to dds (at load time).
>
>
>
> There is a very tiny C library that can work with DDS and some of its
> compression format.
> It is named as SOIL library( http://lonesock.net/soil.html ).If this library
> seems promising
> it can be a starting point for the project.

Blender is already using a DDS library that supports DXT. In fact, I
have a patch laying around to add compression support to the BGE (at
least, I think it was working, I didn't have a program to monitor
texture memory usage to be sure though). However, I ran into issues on
the Blender side. I can give you what I have if you want to play with
it. However, even without the patch, I don't think this would take
more than a week or two (at most).

Cheers,
Mitchell Stokes (Moguri)