Is there something that sinks the motion actuator movement with a walk cycle movement.I think that would be a good feature.
Originally Posted by 3d solar system builder View Post
Parent to nearest object with a paticular property for a minecraftlike game.In built animation library with a menue of selectable animations that would automatically be applied to the armature when you select one and the armature.
And a advanced dialogue system built into the game engine.
Why would it have to be a specific rig.Why can’t the animation be made to conform to any rig.After all they are just rotations.And you also would be allowed to modify them how you like.Makehuman does something similar but for meshes not animations.They could be a base for your animations for characters.You could still make your own animations for characters from scratch if you like.
Ilumination/graphics:
-Shadows:
–Cascaded shadows.
–Point light shadows.
–Smooth shadows (are like variance shadows, but this have a better perfomance and is different)
(what happened with the work of kupoman on the ilumination?)
–If is possible, increase the perfomance of the shadows already has the bge.
–The mist have a little effect unwanted, if you have a material with “Use mist” deactivate(a skybox), the objects over the material in the mist will have the color of the world color, and not the color of the material it has the “Use mist” deactivate.
-Lights:
–Area lights(is there a patch for it)
Programing/logic:
-Some python functions about the physics:
–Set ghost.
–Linked collision in the setConstraint()
–Set physic collision mask.
Other:
-Constraint in objects working with groups(is there a patch for it)
-Maybe more constraints working in the bge(maybe is not so usefull, things like this can do it with python).
It has to be a specific rig because those animations aren’t only rotations. Each bone has it’s own rotation and location values during the animation, so if you want to use an animation from another rig (Pre-made animations) it would most likely screw up your own rig.
The only way i can see this being used is to have a pre-made rig for simple characters and testing.
The Bgui is really great, it even got a progressbar. My consern is with Android, is it gonna work on mobile and what would be the drawcall?
This sounds like you want a built-in state machine library for Python (this sounds too complicated for logic bricks). I think this would be better as a separate library similar to Bgui.
Yes true, but what about speed? Isnt the AI better to be written in c++ and some python api to access it., again what about Android speed?
Object Pool:Improve performance and memory use by reusing objects from a fixed pool instead of allocating and freeing them individually. Taken from here: http://gameprogrammingpatterns.com/object-pool.html
As mentioned, we have addons that can do this, but something built-in would probably be nice. Unfortunately, Blender’s existing particle UI doesn’t lend itself too well to game particles. Some thought would have to be put into this to make a good user experience instead of some hack.
You mean there gonna have to be 2 particle systems?
So in order to have a second scripting language you have to rewrite a lot of parts.
Fixing bugs. Fixing the bugs that are present in the BGE is always a nice thing to do.
Speeding up rendering. I’m not sure what could be done about this, or if it’s just a matter of how 3D engines draw things on-screen. Maybe the existing shaders could be reduced for the sake of speed, or perhaps a “game engine ready” shader could be added that’s really the bare minimum in terms of lighting and stuff. I seem to recall Moguri asked about the possibility of cutting down the existing shaders in favor of a faster, uber-shader, or something to that effect. Maybe a new shader could just be added that has this advantage, while leaving the old shaders in existence. If it’s just a matter of “this is as fast as we can get the BGE to draw individual draw calls”, then it would be nice to see some work on the next point.
Vertex adding / removal, mesh “merging”. Moerdn’s work on this matter was not without results, so I know both should be possible. It would really help out with optimizations when one’s dealing with complex things, since you could merge meshes together in a single draw-call. It’d really be useful in dynamic games like Minecraft, or other randomly generated games, or just in normal games that have separated objects placed beforehand (trees, houses, shrubs, fences, etc). Vertex adding and removal would also be nice since it would allow one to merge objects themselves if they felt the need (and merging wasn’t implemented).
EDIT: Even if mesh merging requires that it merge into an existing material on the object, it wouldn’t be hard to set that up beforehand.
Speeding up Python execution. I’m not sure how practical this is, but there are Python interpreters or compilers (PyPy and Cython) that could possibly be of assistance. For PyPy, it would look like it’s a complete replacement for the existing Python interpreter (CPython, the default one) that comes with Blender, and is in beta for Python 3.x. Cython seems to be a library that compiles existing code, so it would have to be packaged with Blender / the existing Python distribution. However, it doesn’t seem to interfere with the existing interpreter, so I think it’d be easier to implement, and seems to fully support Python 3.
Note that this is just me looking at these options for a couple of minutes - I don’t know much about the details, and I’m sure Moguri’s been keeping his eyes on them.
Now, why should Python execution be sped up (especially after what Moguri mentioned)? Well, if Python execution were sped up, then we could implement our own solutions for some problems in Python and have them work sufficiently. For example, I actually have a working new version of X-Emitter that will display particles much faster than the original implementation, but actually moving the particles still requires Python. Most of the time spent with the new X-Emitter is on moving vertices of meshes after performing the necessary calculations on them, which is how it displays so fast. If I could optimize this to run 100x, 10x, or even just 4x faster through the use of Cython’s static C definitions, for example, then I think it would really open up the possibilities.
Area lights would be extremely useful. I’m not sure how useful martish’s patch would be anymore, but I’d still really like to see it implemented.
Inferred lighting would be nice, of course, if Kupoman still wanted to pursue it.
As a really small feature request, it would be extremely helpful for my X-Emitter system if a new “Halo” mode could be added so that it pivoted faces around their centers rather then the object’s center. Maybe I’ll work on this myself if I have time / if people want a new X-Emitter enough.
As a side-note, Moguri made a patch that separated shadow casting objects from the mesh (i.e. you can have an invisible object that casts a shadow) that was really useful. I hope I see that committed once 2.7 is released and Blender’s out from “lock-down”.
Off-topic: It seems like Blender’s been in RC-stage for quite some time now. I wonder if something went wrong.
Regarding Cython - it’s a pre-interpreter step that compiles Python files into C modules. You can already do this, though I find it to be a hassle.
PyPy is out of the question for some time until the C api (which is how CPython talks to C code) is properly implemented, as it doesn’t play nicely at present.
Now, why should Python execution be sped up (especially after what Moguri mentioned)? Well, if Python execution were sped up, then we could implement our own solutions for some problems in Python and have them work sufficiently. For example, I actually have a working new version of X-Emitter that will display particles much faster than the original implementation, but actually moving the particles still requires Python. Most of the time spent with the new X-Emitter is on moving vertices of meshes after performing the necessary calculations on them, which is how it displays so fast. If I could optimize this to run 100x, 10x, or even just 4x faster through the use of Cython’s static C definitions, for example, then I think it would really open up the possibilities.
In terms of the AI system suggestions, may I add the suggestions of support for nav-volumes and a system to help AI find paths that go between different navmesh sections that require actions such as going up a ladder, jumping over a pit, or riding a moving platform?
Just throwing it out there as that might be a common problem seen in many AI situations, though I will throw in my support for having faster Python through the means of something like auto-compiling into the Cyphon definition when the game starts.
I believe that Sjoerd submitted a patch to get handlers when the game engine is started. It makes sense to do this compiling in a python addon rather than c++
Either way, it’d be convenient to have Cython pre-installed into Blender’s Python distribution. This would be really nice if you could write your scripts once and just call to compile the scripts whenever you run the game on the OS that you’re using. That way one wouldn’t have to do extra work to compile the scripts on different OSes before distributing the game.
Also Items added to a navmesh from another layer, don’t seem to be able to pathfind, only steer behavior (I could be wrong)
Also, Wrectified will feature ai’s that move along a surface normal,
My demo is set in space, in a rotating torus shaped item for artificial gravity. right now I think I can pull off running along the surface, but jumping through a volume while navigating my cause issues,
Wouldn’t that require openGL 3.2 or greater? Or is that just standard for it?
as for what I would like:
multi-core cpu support.(I’m pretty sure bge doesn’t support this, and wouldn’t it speed up your game?)
-maybe an uptdated version of the Bullet engine, or at least some bugs fixed in this one.
-navmesh avoidance(to avoid objects sitting on the nav-mesh when an object is seeking another object).
-general bugs fixed in bge.
I don’t know if thes ideas are too far fetched or not.
This could possibly be done if the BGE dropped its custom Bullet implementation and borrowed the one developed by Aligorith and Sergof for the rest of Blender (non-GE as Moguri already mentioned).
One of the future goals is to integrate the BGE more deeply in Blender, I don’t think you should expect much, if any slowdown in Physics if the game engine used code from the official implementation because it’s pretty darn fast.
The bonus is that whatever upgrades a dev. makes to the Bullet implementation will benefit BGE users as well.
One thing I just thought of, one advantage of having an auto-compilation of Python scripts into the Cython definition is that it could be part of a general system that could also create dramatic speedups for general Blender addons as well (creating great benefit for tools like the Ivy Generator).
So you have the BGE and Blender sharing this implementation and everyone in the community benefits.
It depends on the application and how it’s implemented (i.e. simply compiling the script with Cython might net you some speed-up, but statically typing your data types and function definitions is supposed to help tremendously). The homepage has a “Faster code via static typing” article that shows results from 35% speedup to 150x faster.
Actually, not quite, but there are very very few things I want:
Better documentation in a human-readable manner (not a coder readable manner, human readable: for those mortals who sit at computers and use mice.) I find it a shame that tutorialsforblender3D has a better API interface than the official page.
Consistent Python API Style (CamelCase vs under_score) Possibly removal of deprecated functions
My consern is with Android, is it gonna work on mobile and what would be the drawcall?
If I could optimize this to run 100x, 10x, or even just 4x faster through the use of Cython’s static C definitions, for example, then I think it would really open up the possibilities.
If I could optimize this to run 100x, 10x, or even just 4x faster through the use of Cython’s static C definitions, for example, then I think it would really open up the possibilities.