This patch improves clock management in BGE, to be able to accelerate /
slow the time, and also to finely synchronize clock with external
engines. Several new python functions have been added and existence ones
have been improved for that purpose. Now we have:
- getClockTime(): Get the current BGE render time, in seconds. The BGE
render time is the simulation time corresponding to the next scene that
will be rendered.
- getFrameTime(): Get the current BGE frame time, in seconds. The BGE
frame time is the simulation time corresponding to the current call of
the logic system. Generally speaking, it is what the user is interested
in.
- getRealTime(): Get the number of real (system-clock) seconds elapsed
since the beginning of the simulation.
- getTimeScale(): Get the time multiplier between real-time and
simulation time. The default value is 1.0. A value greater than 1.0
means that the simulation is going faster than real-time, a value lower
than 1.0 means that the simulation is going slower than real-time.
- setTimeScale(time_scale): Set the time multiplier between real-time
and simulation time. A value greater than 1.0 means that the simulation
is going faster than real-time, a value lower than 1.0 means that the
simulation is going slower than real-time. Note that a too large value
may lead to some physics instabilities.
- getUseExternalClock(): Get if the BGE use the inner BGE clock, or rely
or on an external clock. The default is to use the inner BGE clock.
- setUseExternalClock(use_external_clock): Set if the BGE use the inner
BGE clock, or rely or on an external clock. If the user selects the use
of an external clock, he should call regularly the setClockTime method.
- setClockTime(new_time): Set the next value of the simulation clock. It
is preferable to use this method from a custom main function in python,
as calling it in the logic block can easily lead to a blocked system (if
the time does not advance enough to run at least the next logic step).
Rationale are described more precisely in the thread
http://lists.blender.org/pipermail/bf-gamedev/2013-November/000165.html.
See also T37640
Reviewers: sybren, panzergame, #game_engine, lordloki, moguri
Reviewed By: sybren, panzergame, #game_engine, lordloki, moguri
Subscribers: moguri, hg1, sybren, panzergame, dfelinto, lordloki
Projects: #game_engine
Maniphest Tasks: T37640
Differential Revision: https://developer.blender.org/D728
Binding code was re-building its own DM for the cage, now it uses given one instead.
I cannot see really any good reason not to use 'visual' modified cage for binding process,
using base mesh instead was breaking any 'advanced' binding as described in the report.
C++ does not allow the assignment of a void pointer to a typed pointer without
explicit casting. Since we use a generic macro in bmesh for iterators we only
ever get a void* back and cannot cast it to the target type. However, casting
the target to a void* as well solves that issue.
This tweak is #ifdef'd to be used in C++ code only.
This uses a bmesh-intersection, BLI_kdtree and watertight intersections to perform boolean operations.
For now keep both BMesh and Carve booleans usable at once for testing & bug reports,
however we plan to phase out Carve by next release.
Works much the same as intersect operator,
expose as a new operator since for users its quite different.
Access from face menu.
Internally, this adds boolean args to BM_mesh_intersect function.
FBOs are a GL 3.0 feature but enjoy nearly universal support via
extensions.
The newer ARB extension brings these features to GL 2.1 without needing
an ARB suffix.
The older EXT extensions *do* use a suffix. Since we don’t know which
is used until runtime, I added the suffix to all functions & enums.
Also updated the check to look for the FBO feature set instead of the
specific EXT extension.
Maybe this is pedantic but I read it’s best to explicitly set the
desired component size.
Also append “_ARB” to float texture formats since those need an
extension in GL 2.1.
This class did nothing but print out extensions if they were found.
Instead, the code from bge.logic.PrintGLInfo() is now printed as the
Rasterizer is initialized. This gives better information, and it removes
some GL code from KX_PythonInit.cpp (the PrintGLInfo method now calls
the Rasterizer to print the information).
Differential Revision: https://developer.blender.org/D438
The only use we had for RAS_StorageIM was to render derived meshes using
Blender's mesh drawing. This is now handled as a special case in
RAS_OpenGLRasterizer instead of in RAS_StorageIM.
We are now left with RAS_StorageVA and RAS_StorageVBO. At the moment
vertex arrays are still the default since our vertex array with display
lists implementation is still much faster than our VBO code in a lot of
cases. As we improve our VBO code, we can drop vertex arrays since
Blender's minimum OpenGL version is being bumped up to 2.1, which
supports VBOs.
Is current context compatible with legacy GL (version 2.1)?
My earlier approach -- checking for GLEW_ARB_compatibility -- was not
enough.
This should always return true if we set our GL context up properly. It
will return false when we switch to core profile.
Would be true in most cases (and in particular with own generated geometry),
but in case one would be using original geometry this could have crashed badly.
Note that I tried to parallelize the loops porting result of the simulation to the
DM data itself, but that ended up being 20% slower than non-threaded code!
