from Alberto Santos (dnakhain)
Changed "None" to "" for returning an unset vertex group.
"" is a valid name for a vertex group this is asking for trouble.
Its still not working right in perspective mode.
For bleed use a faster method then Barycentric weights function since the point is always on the edge.
last commit with memset in readfile.c missed one var.
fix this by freeing the lib-file-data after linking or appending, re-appending will be slower now
(as slow as appending for the first time).
Not strictly needed, set the memory for bhead's to zero in readfile.c since comparisons are done later on with this data making valgrind complain.
Added some missing headers too.
This made it not refresh the module when taking an external BGE Module and making it internal because the external pyc would never be freed so the internal text wouldn't get used until restarting blender.
--- Notes from Roelf, maybe some other BGE devs could help resolve these
Here is what I have so far. I've left "TODO's" were there needs to be some more comments.
The following things also need to be resolved:
-KX_VehicleWrapper.getWheelOrientationQuaternion looks like it should return a quaternion but if I look at the code it looks like it returns a rotation matrix.
-I still need to find out what exactly KX_VehicleWrapper.getWheelRotation is. I've got the return type but I would like to add some explanation for what it actualy means (and units if any).
-BL_Shader.setNumberOfPasses ignores the parameter but from the comment in the code it looks like the parameter that is being set (it is harcoded to be =1) in setNumberOfPasses is not used. So I'm not sure if this method should be documented at all.
nobody seriously uses this format for graphics these days, and if they did, the export from blender is unlikely be to be useful, its just different views of the mesh edges projected into a 2D xfig file (quantized to int's too).
from Kevin Morgan (forTe)
imports images as quads in the 3D view
made some changes
- images that fail to import give an error popup rather then a script error
- extension input is only shown for batch directory importing
- extension comparison is now case insensitive
- importing images from "/" failed, (bug in Blender.sys.dirname), use os.path.dirname since os is needed for batch import in other places.
- disable Esc for quitting because escaping from the file selector would quit the script too.
Minor changes are...
- default size is smaller then it was but still too big IMHO, presets are huge.
- deselect all objects and make the new bolt active
- place the new bolt at the 3D cursor location
This commit extends the technique of dynamic linked list to the logic
system to eliminate as much as possible temporaries, map lookup or
full scan. The logic engine is now free of memory allocation, which is
an important stability factor.
The overhead of the logic system is reduced by a factor between 3 and 6
depending on the logic setup. This is the speed-up you can expect on
a logic setup using simple bricks. Heavy bricks like python controllers
and ray sensors will still take about the same time to execute so the
speed up will be less important.
The core of the logic engine has been much reworked but the functionality
is still the same except for one thing: the priority system on the
execution of controllers. The exact same remark applies to actuators but
I'll explain for controllers only:
Previously, it was possible, with the "executePriority" attribute to set
a controller to run before any other controllers in the game. Other than
that, the sequential execution of controllers, as defined in Blender was
guaranteed by default.
With the new system, the sequential execution of controllers is still
guaranteed but only within the controllers of one object. the user can
no longer set a controller to run before any other controllers in the
game. The "executePriority" attribute controls the execution of controllers
within one object. The priority is a small number starting from 0 for the
first controller and incrementing for each controller.
If this missing feature is a must, a special method can be implemented
to set a controller to run before all other controllers.
Other improvements:
- Systematic use of reference in parameter passing to avoid unnecessary data copy
- Use pre increment in iterator instead of post increment to avoid temporary allocation
- Use const char* instead of STR_String whenever possible to avoid temporary allocation
- Fix reference counting bugs (memory leak)
- Fix a crash in certain cases of state switching and object deletion
- Minor speed up in property sensor
- Removal of objects during the game is a lot faster
controller.actuators[name] and controller.sensors[name]
Made a read-only sequence type for logic brick sensors and actuators which can access single items or be used like a list or dictionary.
We could use a python dictionary or CValueList but that would be slower to create.
So you can do...
for s in controller.sensors: print s
print controller.sensors["Sensor"]
print controller.sensors[0]
sensors = list(controller.sensors)
This sequence type keeps a reference to the proxy it came from and will raise an error on access if the proxy has been removed.
Commit 20099 started using a FBO way too big.
According to Paul Bourke this is how it's done in other Engines:
Projectors HD:
1920x1050 - buffersize = 1024; FBO size = 2048
1400x1050 - buffersize = 1024; FBO size = 2048
Projectors XGA:
1024x768 - buffersize = 512; FBO size = 1024
Now in Blender Game Engine we are using:
Projectors HD:
1920x1050 - buffersize = 1050; FBO size = 2048
1400x1050 - buffersize = 1050; FBO size = 2048
Projectors XGA:
1024x768 - buffersize = 768; FBO size = 1024
(I guess I should be committing code to the ge_dome branch instead of the trunk. I feel bad doing all those adjustments in a hurry to 2.49 final release in the trunk. That is ok, right?)
*) a small note:
In the end it turned out that we have upright and downright domes out there.
So I may rearrange the order of the gui later:
(1 = fisheye, 2 = truncated up, 3 = truncated down, 4 = envmap, 5 = spherical panoramic)
I don't plan to do a doVersion() for that, so if you are using it already keep in mind that the modes may change before 249 final release.
After last commit (20099) warping meshes got slower (more quality == less performance). Since we don't need an extra warping for truncated domes, It's better to handle them directly in openGL without the need of warping it.
I'll talk with some Dome owners to see if we need both Upright and Downright modes. I may remove one of them by 2.49 them.
*) also: a proper GLEW_EXT_framebuffer_object check before generating FBO (for warping meshes).
**) next in line (maybe after RC2): tilt option to tilt the camera up to 90º upward.
We are using an image twice as big to render the fisheye before warping.
It'll slow down warping meshes a little, but we get way more resolution.
Therefore I will bring Truncated Dome mode back in order to avoid using warping mesh for that.
not fixed but the problem is now less bad when projection painting, bilinear interpolation was rounding down.
- added gameOb.attrDict to get the internal gameObject dict.
- mesh.getVertex wasnt setting an exception.
This commit extend the technique of dynamic linked list to the mesh
slots so as to eliminate dumb scan or map lookup. It provides massive
performance improvement in the culling and in the rasterizer when
the majority of objects are static.
Other improvements:
- Compute the opengl matrix only for objects that are visible.
- Simplify hash function for GEN_HasedPtr
- Scan light list instead of general object list to render shadows
- Remove redundant opengl calls to set specularity, shinyness and diffuse
between each mesh slots.
- Cache GPU material to avoid frequent call to GPU_material_from_blender
- Only set once the fixed elements of mesh slot
- Use more inline function
The following table shows the performance increase between 2.48, 1st round
and this round of improvement. The test was done with a scene containing
40000 objects, of which 1000 are in the view frustrum approximately. The
object are simple textured cube to make sure the GPU is not the bottleneck.
As some of the rasterizer processing time has moved under culling, I present
the sum of scenegraph(includes culling)+rasterizer time
Scenegraph+rasterizer(ms) 2.48 1st round 3rd round
All objects static, 323.0 86.0 7.2
all visible, 1000 in
the view frustrum
All objects static, 219.0 49.7 N/A(*)
all invisible.
All objects moving, 323.0 105.6 34.7
all visible, 1000 in
the view frustrum
Scene destruction 40min 40min 4s
(*) : this time is not representative because the frame rate was at 60fps.
In that case, the GPU holds down the GE by frame sync. By design, the
overhead of the rasterizer is 0 when the the objects are invisible.
This table shows a global speed up between 9x and 45x compared to 2.48a
for scenegraph, culling and rasterizer overhead. The speed up goes much
higher when objects are invisible.
An additional 2-4x speed up is possible in the scenegraph by upgrading
the Moto library to use Eigen2 BLAS library instead of C++ classes but
the scenegraph is already so fast that it is not a priority right now.
Next speed up in logic: many things to do there...
