- added new mathutils.Color() type, use with rna so we can do for eg:
material.diffuse_color.r = 1.0
# also has hsv access
material.diffuse_color.s = 0.6
- made Mathutils and Geometry module names lowercase.
In Blender 2.49 the win width and height were been calculated including an extra pixel (e.g. a fullscreen editor would be (width + 1) by (height + 1) )
In opposite to that, Blender 2.5 window/editor code were fixed to have the exact width,height size.
So although the BGE canvas code was still the same as 2.49 it was producing a wrong result.
I'm also adding some commentaries in the setViewport code. BGE is setting the viewports 1 pixel larger.
the setViewport command is been used as if one should pass (minx, miny, width, height), while it should be (minx, miny, maxx, maxy). I will take care of that later, if any one has extra comments on that, please let me know.
We have already a .sh file to build epydocs from Linux, so why not to have it in Windows as well ;) I think that this guide can help people interested in help with the API documentation to test their work.
I'm actually already in touch with at least one volunteer helping with PhysicsConstraints module. VideoTexture may not be a one man job though, for I hope this document can also help.
1) glCopyTexImage2D - www.opengl.org/sdk/docs/man/xhtml/glCopyTexImage2D.xml
2) dome post_draw. Now dome mode can also use scene.post_draw. It only runs for the last scene. It's really useful. I'm working on a nice showcase for this (a dome visualizer for the dome mode running with bgl. In the mean time this is a (lame) example of both working together (the buffer is being copied and draw on top of the window):
http://blenderecia.orgfree.com/blender/tmp/dome_bgl_copytex2d.jpg
of course it wasn't only a matter of adding the properties in the api :)
The code of validValueForIntervalProperty and modeChange are the same BUT in the future they shouldn't be, for I think it's fine to keep them as separated functions.
Bonus fix: Also we are now checking if the new mode is interval and update the range expression.
Now if you have a VideoTexture.Texture you can use its id and draw it with bgl
The Id is only going to be valid if the obj you are getting the VideoTexture.Texture from has a valid texture. In the examples you will see them as planes, that become invisible at load time, but are needed to validate the texture id.
This is a simple example file:
http://blenderecia.orgfree.com/blender/bind_id_simple.blend
And a (much) more advanced one:
http://blenderecia.orgfree.com/blender/bind_id.blend
(get also this image and save it to the same folder of your blend file - http://blenderecia.orgfree.com/blender/mask.png )
Benoit, I couldn't decide on better names so for now I'm glad with this one.
* 'Export Keying Set' operator works again - a change in the previous commit broke the created code
* Relative Keying Sets don't get their paths shown
* Keying Set paths show options for inserting keyframes too now
---
Another attempt at fixing compile troubles, and removed some commented out + obsolete stuff.
unrelated changes that ended up being more trouble to commit separate...
- removed BLI_split_dirfile(), was nasty, occasionaly modifying the source string, it could create directories and used the $CWD in some cases. was only used in 2 places in filesel.c, if this gives problems can address without bringing back this function.
renamed BLI_split_dirfile_basic --> BLI_split_dirfile
- view3d_operator_needs_opengl was being called for offscreen render when it wasnt needed.
* gameplayer is now probably not going to build without PNG turned ON.
To fix that it would be necessary to use #ifndef NOPNG around the GPC_Canvas::MakeScreenShot.
Since I don't this function it's working in 2.5 yet it's better to wait for that before doing it.
Originally we had 2DFilters (m_filtermanager) stored in RenderTools. That way filters were stored globally and were being called once per each scene. This was producing two big problems: (1) performance and (2) flexibility of use.
(1) Performance - To run the filters 2X == 2X slower
(2) flexibility of use - Very often we want the filter in the scene but not in the UI for example.
For those reasons I believe that 2DFilters with multiple scenes was very useless or unpredictable. I hope they work fine now.
To make it work as before (2.4) you can simply recreate the 2dfilter actuators across the scenes.
* * * * *
Imagine that we have:
(a) Main Scene
(b) Overlay Scene
in Main Scene the Z Buffer and RGB will be from the main scene.
in Overlay Scene the Z Buffer will be from the Overlay Scene and the RBG buffer is from both [(a + 2D Filter) + b].
So in pseudo code if we have a,b,c,d,e scenes we have: (2DFilterE(2DFilterD(2DFilterC(2DFilterB(2DFilterA(a) + b) + c) + d) + e)
ImageBuff([width,height[,color[,scale]]])
width, height: size of buffer in pixel.
default: buffer not allocated.
color: initial value of RGB channels. Alpha channel is 255.
Possible values: 0(black=default) -> 255 (white)
scale: True or False to enable or disable fast scaling
default: False
This constructors eliminates the need to use the load function
when you just want to initialize the image buffer to black or white.
I forgot to say in the last commit that those arguments are only for the BlenderPlayer.
we can now set external warpdata files.
2Do:
(1) convert relative to absolute paths for warpdata files
(2) investigate weird bug on lack of light in blenderplayer with warpmesh
... [old 2Do]
(3) documentation
(4) preserve scene settings (at least scene->gm.dome) even if you load a new file inside the game (e.g. Yo Frankie loading new levels)
2Do:
(1) open external warpdata file
(2) documentation
(3) preserve scene settings (at least scene->gm.dome) even if you load a new file inside the game (e.g. Yo Frankie loading new levels)
otherwise it's a nightmare to update all your files every time you change your projection system. See note.
Maybe SYS_WriteCommandLineInt/Float/String can be used for that. Gotta investigate further.
* Note: an external warpdata file is a must ! Currently every time you need to calibrate your system you have to update the warp file in all your demo files. This is terrible. I'm glad I *now* have a dome near by to test it ;)
* FYI: A recent 'Yo Frankie in a dome' video if you want to see how it works: http://www.vimeo.com/9629626 I'm going to record a better one tomorrow.
- Use BGL buffer instead of string for image data.
- Add buffer interface to image source.
- Allow customization of pixel format.
- Add valid property to check if the image data is available.
The image property of all Image source objects will now
return a BGL 'buffer' object. Previously it was returning
a string, which was not working at all with Python 3.1.
The BGL buffer type allows sequence access to bytes and
is directly usable in BGL OpenGL wrapper functions.
The buffer is formated as a 1 dimensional array of bytes
with 4 bytes per pixel in RGBA order.
BGL buffers will also be accepted in the ImageBuff load()
and plot() functions.
It is possible to customize the pixel format by using
the VideoTexture.imageToArray(image, mode) function:
the first argument is a Image source object, the second
optional argument is a format string using the R, G, B,
A, 0 and 1 characters. For example "BGR" means that each
pixel will be 3 bytes, corresponding to the Blue, Green
and Red channel in that order. Use 0 for a fixed hex 00
value, 1 for hex FF. The default mode is "RGBA".
All Image source objects now support the buffer interface
which allows to create memoryview objects for direct access
to the image internal buffer without memory copy. The buffer
format is one dimensional array of bytes with 4 bytes per
pixel in RGBA order. The buffer is writable, which allows
custom modifications of the image data.
v = memoryview(source)
A bug in the Python 3.1 buffer API will cause a crash if
the memoryview object cannot be created. Therefore, you
must always check first that an image data is available
before creating a memoryview object. Use the new valid
attribute for that:
if source.valid:
v = memoryview(source)
...
Note: the BGL buffer object itself does not yet support
the buffer interface.
Note: the valid attribute makes sense only if you use
image source in conjunction with texture object like this:
# refresh texture but keep image data in memory
texture.refresh(False)
if texture.source.valid:
v = memoryview(texture.source)
# process image
...
# invalidate image for next texture refresh
texture.source.refresh()
Limitation: While memoryview objects exist, the image cannot be
resized. Resizing occurs with ImageViewport objects when the
viewport size is changed or with ImageFFmpeg when a new image
is reloaded for example. Any attempt to resize will cause a
runtime error. Delete the memoryview objects is you want to
resize an image source object.
... what lead me to wonder if we should remove obj.setAngularVelocity, obj.setLinearVelocity, obj.getLinearVelocity and obj.getAngularVelocity.
* this was so Copy and Paste ... anyways tests are welcome (I never used those methods in python myself).
- recode of the whole sequencer audio handling
- encode audio flag removed, instead you choose None as audio codec, added None for video codec too
- ffmpeg formats/codecs: enabled: theora, ogg, vorbis; added: matroska, flac (not working, who can fix?), mp3, wav
- sequencer wave drawing
- volume animation (now also working when mixing down to a file!)
- made sequencer strip position and length values unanimatable
