I made a concept how visual scripting could look like in blender. maybe i will do some more concepts on that.
new features are nodal logic, global properties, and the ability to choose between node-logic and logic-bricks.
uh, it’s good your concept. It would be nice have nodal logic on bge.
I can almost guarantee you that nodal logic would be more complex than attaching sockets to the logic bricks and copying them to node form, node editors would allow new ideas and new brick types built to take full advantage of a node environment and also the possibility of new socket types like ones that accept boolean values and string inputs (the gamekeys module comes to mind here)
As for existing bricks, a lot of sensors would have inputs too, like the mouse sensor might have an input to set a value to switch between the different buttons and an input to set the sensitivity dynamically, or the keyboard sensor could have a string input that allows you to change the keyboard controls dynamically without needing additional keyboard sensors connected to property sensors.
just a curiosity, but when you talk about the new rasterizer, do you mean? What is the Point? increases the speed?
I hope you’re not using a laptop! (coputer)
Blender on my PC is like a bomb, is faster than the PS2!
:eek:
Yes, i am on a GTX 460, i5 760, 4GB ram, and i still manage to get slowdown in areas i shouldn’t!
@moerdn - Why does the BGE render one object per batch? Does it have something to do with materials or something?
I know it renders one material per batch, even if this material is shared by multiple object. This happens for efficiency of passing the data to the gpu, in fact the material is on vertex base. In reality at conversion time all the vertices are grouped together by material and stored in this way. Everything IIRC
There a lot of ways to optimize rendering. One thing is grouping objects with same material and shaders together in a so called ‘material bucket’. This should be done to minimize opengl state switches and that is actually done by bge.
Lets assume you have three materials A, B, C and some mesh slots that are linked to these materials
unoptimized rendering could look like this:
A | B | C | A A | C | B B | C C - 6 state switches
optimized rendering: A A A | B B B | C C C C - 3 state switches
The next way to speed up rendering is the batching of these mesh slots, to render a bunch of slots together with one single opengl render call.
A+A+A B+B+B C+C+C+C
batch A | batch B | batch C
You can test this easily on your own: Render one object with a million polygons and bge would render very fast.
0.1 ms rasterizer for two million tris (geforce 275 gtx)
But rendering of thousand individual objects like simple cubes with 12.000 tris in total takes 3.5 ms. Join all of theses individual objects together and rendering would be fast again.
Now the idea is to join these individual objects dynamically after process of culling, LODing and bucket sorting.
If there are some ideas on how to achieve this, please leave a comment at the rasterizer proposal thread. With a good batch rendering, bge rasterizer would be fast enough and the lod system would scale much better.
greetings,
moerdn
box or laptop?
in my , some defect (image seems cut) but not slow
much slowdowns see if using subsurf
a little generic, but…
BOX
SO Win7 64bit
CPU 2.80GHz dual core(33°)
RAM 2GB
Graphic Card 512 MBGeForce 8400 GS (46°C )
Tower (BOX)
Have we reached any conclusions or something?
Also is implementing openssl into BGE for encryption/closed source would work?
I’m considering starting a seperate thread, on the result of this poll (Rasterizer bottlenecks) and working on some analysis of where the problems lie.
I know this thread seems about done, but when it comes to wanting to see more BGE development, Moguri is starting to commit some of his patches to trunk as a result of the feature freeze being over, beginning with the option for certain objects/materials to not cast shadows.
http://lists.blender.org/pipermail/bf-blender-cvs/2011-August/038887.html
Those who wanted to see more features officially added to the BGE, you’re getting it 
YES. AWESOME. This is a great addition. The BGE has gotten quite a bit of attention recently. Not just bug-fixes, but new additions and such. Thanks to the developers, including Moguri!
What needs to change is the bottleneck, which is holds us back from using the latest techniques (regarding speed and quality)
Didn’t vote since I do not know what it is that holds back the BGE the most.
(good poll!)
Not as important but some more high-level support for Networking would be nice.
Using Python sockets is pretty discouraging.
So maybe implement support for it on a C++ level.
Anicator: I suggested this on Blenderstorm but they told me that networking should be done with Python. However I still think it would be nice to have but it is not the top priority. Rendering engine should be the priority #1 for now. But better networking support will be still very nice to have since we will not be inventing the wheel from the beggining
P.S. I heard that BGE renders one object per batch and speedup can be achieved by sending multiple objects in one batch. It was mentioned multiple times, i think I will look into that code and see if I can do something about it (but im total c++ noob)
Track to nearest pathnode when switching from path follow on the steering actuator to that script that does that. That is what i would like.