Used F11 and friends for its special keys Stop,again etc..
So this little patch enables F11 and F12 to work as expected
following link has documentation on it:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4734408
also from /usr/include/X11/Sunkeysym.h
#define SunXK_F36 0x1005FF10 // Labeled F11
#define SunXK_F37 0x1005FF11 // Labeled F12
I also added a comment explaning why the heck its there...
What this means is XK_F11 and XK_F12 do not line up with the F11 and F12
keys on sun keyboards. So I've added special cases to correct the issue.
Doing a quick grep for XK_F shows there are some files in the
gameengine that use them when they probably shouldn't, but I'm not going to
attempt to fix them, Files that should be looked at are:
gameengine/BlenderRoutines/KX_BlenderInputDevice.h
gameengine/Converter/KX_ConvertSensors.cpp
gameengine/GameLogic/SCA_IInputDevice.h
gameengine/GamePlayer/common/unix/GPU_KeyboardDevice.cpp
gameengine/GamePlayer/common/windows/GPW_KeyboardDevice.cpp
gameengine/GamePlayer/ghost/GPG_KeyboardDevice.cpp
gameengine/Ketsji/KX_PythonInit.cpp
Kent
This should bring the projectfiles upto date for msvc7.
Moving these to version 7.1 so that the version 8 people don't have such a hard time importing into 2005.
Build intern.sln, extern.sln and then blender.sln. Enjoy. :p
variable blah at a higher scope is already defined...
(one of these was introduced by me when I moved a variable declaration
to the top of the function.)
Kent
Try to get the yy_wrap and yy_parse definitions for IRIX. Hoping
that it will also help Kent's multiply resolved warnings, I've done
this so that these symbols are defined only if they are currently
undefined. I'm not sure if it will work though, please test!
BOP_Mesh.h:45: warning: ‘class BOP_Mesh’ only defines private constructors and h
as no friends
drawimasel.c initalized a variable so it didn't give warnings about it.
(wasn't really needed but if the code changes could be potential issue)
Kent
- Added part of Austin's msvc8 fixes (vector::erase function
was "misused"), hopefully compiles better now.
- Ctrl-b now also bakes a selected fluidsim domain
similar to the softbodies.
- Added surface smoothing option for domains: default is
1, higher values result in a smoother surface (and probably
slightly higher comupation times), while 0 means the surface
is not modified at all.
- Added BLENDER_ELBEEMBOBJABORT environment variable in readBobj,
if >0 quits blender when a not yet existing fluidsim
frame should be loaded. Useful for rendering simulations
as far as possible from the command line.
- Surface normals pointer is now set to NULL in readfile.c
- Fixed win32 error string handling, now uses a function
to return the string from the solver.
- Fixed fluidsim particle halo scaling problem.
- Solver update
a string as an int and it was causing a warning.
I changed it to check to see if the string == 0
return 0 else return 1.
The only thing that called this function was memtest.c and it
had outdated code, so I fixed that...
was calling MEM_set_error_stream updated to
MEM_set_error_callback
Kent
* These changes bring cross-compiling Blender for Windows on Linux one step
closer to reality. The 'biggest' change is in makesdna SConscript to make
sure a linux native makesdna is built, that can be run, too. Next to that
proper checks for env['OURPLATFORM']=='linuxcross' are added in various
places.
Switch change in pluginapi.c was necessary, and AFAIK it should work like
that also on WIN32, if not, slap me.
Note: everything *compiles* now nicely, it is just that the final *linking*
doesn't work (yet). Anyone who fixes this will be the
hero of cross-compilers :)
no GE right now ( need to adapt to erwins file reshuffle
so may be i wait a bit until he has his mind made up )
elbeem is running when you remove the extra std:: at some places
well the msvc6 preprocessor is not very smart
--> std:: is not a member of std:: :)
so i guess there is a "using namespace std" somewhere
issues in parallel... So this commit contains: an update of
the solver (e.g. moving objects), integration of blender IPOs,
improved rendering (motion blur, smoothed normals) and a first particle
test. In more detail:
Solver update:
- Moving objects using a relatively simple model, and not yet fully optimized - ok
for box falling into water, water in a moving glass might cause trouble. Simulation
times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot
might also cause slowdowns.
- Additional obstacle settings: noslip (as before), free slip (move along wall freely)
and part slip (mix of both).
- Obstacle settings also added for domain boundaries now, the six walls of the domain are
obstacles after all as well
- Got rid of templates, should make compiling for e.g. macs more convenient,
for linux there's not much difference. Finally got rid of parser (and some other code
parts), the simulation now uses the internal API to transfer data.
- Some unnecessary file were removed, the GUI now needs 3 settings buttons...
This should still be changed (maybe by adding a new panel for domain objects).
IPOs:
- Animated params: viscosity, time and gravity for domains. In contrast
to normal time IPO for Blender objects, the fluidsim one scales the time
step size - so a constant 1 has no effect, values towards 0 slow it down,
larger ones speed the simulation up (-> longer time steps, more compuations).
The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect).
- For objects that are enabled for fluidsim, a new IPO type shows up. Inflow
objects can use the velocity channels to animate the inflow. Obstacles, in/outflow
objects can be switched on (Active IPO>0) and off (<0) during the simulation.
- Movement, rotation and scaling of those 3 types is exported from the normal
Blender channels (Loc,dLoc,etc.).
Particles:
- This is still experimental, so it might be deactivated for a
release... It should at some point be used to model smaller splashes,
depending on the the realworld size and the particle generation
settings particles are generated during simulation (stored in _particles_X.gz
files).
- These are loaded by enabling the particle field for an arbitrary object,
which should be given a halo material. For each frame, similar to the mesh
loading, the particle system them loads the simulated particle positions.
- For rendering, I "abused" the part->rt field - I couldnt find any use
for it in the code and it seems to work fine. The fluidsim particles
store their size there.
Rendering:
- The fluidims particles use scaled sizes and alpha values to give a more varied
appearance. In convertblender.c fluidsim particle systems use the p->rt field
to scale up the size and down the alpha of "smaller particles". Setting the
influence fields in the fluidims settings to 0 gives equally sized particles
with same alpha everywhere. Higher values cause larger differences.
- Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals
computed by the solver are used. This is basically done by switching off the
normal recalculation in convertblender.c (the function calc_fluidsimnormals
handles other mesh inits instead of calc_vertexnormals).
This could also be used to e.g. modify mesh normals in a modifier...
- Another change is that fluidsim meshes load the velocities computed
during the simulation for image based motion blur. This is inited in
load_fluidsimspeedvectors for the vector pass (they're loaded during the
normal load in DerivedMesh readBobjgz). Generation and loading can be switched
off in the settings. Vector pass currently loads the fluidism meshes 3 times,
so this should still be optimized.
Examples:
- smoothed normals versus normals from subdividing once:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.pnghttp://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png
- fluidsim particles, size/alpha influence 0:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png
size influence 1:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png
size & alpha influence 1:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png
- the standard drop with motion blur and particles:
http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg
(here's how it looks without
http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg)
- another inflow animation (moving, switched on/off) with a moving obstacle
(and strong mblur :)
http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg
Things still to fix:
- rotating & scaling domains causes wrong speed vectors
- get rid of SDL code for threading, use pthreads as well?
- update wiki documentation
- cool effects for rendering would be photon maps for caustics,
and motion blur for particles :)
+ the code in writemovie.c no longer compiles (since the renderer
refactor). I have #if 0-ed it.
+ OpenGL on Irix doesn't have GL_ARB_vertex_program
+ mmap on Irix doesn't like MAP_ANON.
+ If using the MipsPro 7.3 compiler, the variable MIPS73_ISOHEADERS
can be set to point to the directory with those weird C++ headers
that don't have .h in the name
In Orange we've been fighting the past weeks with memory usage a lot...
at the moment incredible huge scenes are being rendered, with multiple
layers and all compositing, stressing limits of memory a lot.
I had hoped that less frequently used blocks would be swapped away
nicely, so fragmented memory could survive. Unfortunately (in OSX) the
malloc range is limited to 2 GB only (upped half of address space).
Other OS's have a limit too, but typically larger afaik.
Now here's mmap to the rescue! It has a very nice feature to map to
a virtual (non existing) file, allowing to allocate disk-mapped memory
on the fly. For as long there's real memory it works nearly as fast as
a regular malloc, and when you go to the swap boundary, it knows nicely
what to swap first.
The upcoming commit will use mmap for all large memory blocks, like
the composit stack, render layers, lamp buffers and images. Tested here
on my 1 GB system, and compositing huge images with a total of 2.5 gig
still works acceptable here. :)
http://www.blender.org/bf/memory.jpg
This is a silly composit test, using 64 MB images with a load of nodes.
Check the header print... the (2323.33M) is the mmap disk-cache in use.
BTW: note that is still limited to the virtual address space of 4 GB.
The new call is:
MEM_mapalloc()
Per definition, mmap() returns zero'ed memory, so a calloc isn't required.
For Windows there's no mmap() available, but I'm pretty sure there's an
equivalent. Windows gurus here are invited to insert that here in code! At
the moment it's nicely ifdeffed, so for Windows the mmap defaults to a
regular alloc.
+ 'scons blenderplayer' builds blender AND blenderplayer now (tested on Linux
only, but was only linking issue, so should work on other platforms too).
NOTE: I noticed some compileflags for GE specific libs that were left out -
I re-enabled them in the SConscripts, but I'm going to do a test build my-
self now, so if there are problems with them on win32, I probably already
know about them :)
+ BF_BUILDINFO=1 (by default) for build info in splash
- remove redundant renderconverter include dir
* check for win32-vc instead of only win32, so MingW compile goes ok
* This commit is all of the rewrite work done on the SCons system. For
documentation see doc/blender-scons.txt and doc/blender-scons-dev.txt.
Also http://mediawiki.blender.org/index.php/BlenderDev/SconsRefactoring
contains valuable information, along with what still needs to be done.
- linux, os x and windows compile now.
- files are compiled to BF_INSTALLDIR (see config/(platform)-config.py)
- NOTE: Jean-Luc P will commit sometime during the weekend proper
appit() for OS X. For now, copy the resulting binary to an
existing .app bundle.
- features:
- cleaner structure for better maintenance
- cleaner output during compile
- better handling of build options
- general overall speed increase
- see the wiki for more info
Cygwin, FreeBSD and Solaris systems still need work. For these systems:
1) copy a config/(platform)-config.py to ie. config/cygwin-config.py
2) set the proper defaults for your platform
3) mail me at jesterking at letwory dot net with you configuration. if
you need any modifications to the system, do send a patch, too.
I'll be giving first-aid today and tomorrow, after that it'll be all
regular development work :)
/Nathan
extern/bullet/BulletDynamics/ConstraintSolver/SimpleConstraintSolver.h
added newline at end of file.
intern/boolop/intern/BOP_Face2Face.cpp
fixed indentation and had nested declarations of a varible i used
for multiple for loops, changed it to just one declaration.
source/blender/blenkernel/bad_level_call_stubs/stubs.c
added prototypes and a couple other fixes.
source/blender/include/BDR_drawobject.h
source/blender/include/BSE_node.h
source/blender/include/butspace.h
source/blender/render/extern/include/RE_shader_ext.h
added struct definitions
source/blender/src/editmesh_mods.c
source/gameengine/Ketsji/KX_BlenderMaterial.cpp
source/gameengine/Ketsji/KX_ConvertPhysicsObjects.cpp
source/gameengine/Ketsji/KX_RaySensor.cpp
removed unused variables;
source/gameengine/GameLogic/Joystick/SCA_Joystick.cpp
changed format of case statements to avoid warnings in gcc.
Kent
here is a quick summary...
Kent
intern/bsp/intern/BSP_CSGMesh_CFIterator.h
removed tri_index (unused variable)
intern/bsp/intern/CSG_BooleanOps.cpp
removed extra ;
intern/string/intern/STR_String.cpp
added <ctype.h>
source/blender/blenkernel/BKE_writeavi.h
moved things around so not doing forward declarations
source/blender/renderconverter/intern/convertBlenderScene.c
changed render.h to render_types.h
source/blender/src/blenderbuttons.c
source/blender/src/editgroup.c
source/blender/src/meshtools.c
added newline
source/gameengine/Ketsji/KX_KetsjiEngine.cpp
commented out include "PIL_time.h" code that requires it is commented out
reading blender/src/writeavicodec.c
(struct keyword to a couple of lines that needed it)
and added:
extern struct Render R;
blender/renderconverter/intern/convertBlenderScene.c
added extern Render R;
added #include "rendercore.h" to get rid of undeclared shade_material_loop
(Not sure if this is right but it fixes it.
Did not fix this problem, is it alright to just pass NULL here or should we chan
ge it to something else:
init_render_materials' : too few
gameengine/Physics/BlOde/OdePhysicsEnvironment.cpp
removed argument to dHashSpaceCreate
commented out dWorldQuickStep since it does not exist