Changed one of the intersection tests to use < rather than <=
The sharp and smooth modes look fine now for the special case that was
reported broken; blocks mode looks correct but "jumps" slightly from
one octree resolution to another, so may need additional corrections.
* Multithreaded image loading, each thread can load a separate image.
* Better multithreading for multiple instanced meshes, different threads can now
build BVH's for different meshes, rather than all cooperating on the same mesh.
Especially noticeable for dynamic BVH building for the viewport, gave about
2x faster build on 8 core in fairly complex scene with many objects.
* The main thread waiting for worker threads can now also work itself, so
(num_cores + 1) threads will be working, this supposedly gives better
performance on some operating systems, but did not measure performance for
this very detailed yet.
fix for [#31097] glibc error when playing sound using BGE
by Wander Lairson Costa
Note: This deadlock fix makes the code non-threadsafe again, a proper solution has to be found still.
For sample images see:
http://www.dalaifelinto.com/?p=399 (equisolid)
http://www.dalaifelinto.com/?p=389 (equidistant)
The 'use_panorama' option is now part of a new Camera type: 'Panorama'.
Created two other panorama cameras:
- Equisolid: most of lens in the market simulate this lens - e.g. Nikon, Canon, ...)
this works as a real lens up to an extent. The final result takes the
sensor dimensions into account also.
.:. to simulate a Nikon DX2S with a 10.5mm lens do:
sensor: 23.7 x 15.7
fisheye lens: 10.5
fisheye fov: 180
render dimensions: 4288 x 2848
- Equidistant: this is not a real lens model. Although the old equidistant lens simulate
this lens. The result is always as a circular fisheye that takes the whole sensor
(in other words, it doesn't take the sensor into consideration).
This is perfect for fulldomes ;)
For the UI we have 10 to 360 as soft values and 10 to 3600 as hard values (because we can).
Reference material:
http://www.hdrlabs.com/tutorials/downloads_files/HDRI%20for%20CGI.pdfhttp://www.bobatkins.com/photography/technical/field_of_view.html
Note, this is not a real simulation of the light path through the lens.
The ideal solution would be this:
https://graphics.stanford.edu/wikis/cs348b-11/Assignment3http://www.graphics.stanford.edu/papers/camera/
Thanks Brecht for the fix, suggestions and code review.
Kudos for the dome community for keeping me stimulated on the topic since 2009 ;)
Patch partly implemented during lab time at VisGraf, IMPA - Rio de Janeiro.
Any identifier that looks like an OpenGL identifier, but isn't, causes a false alarm by the glreport.py tool. Most of these were in comments so I just rephrased the comments. There were a couple of static functions/macros that were easy enough to rename. Only the glTexco and glIndex fields of the DMVertexAttribs struct was public and had non-local uses.
Most of the changes are related to adding support for motion data throughout
the code. There's some code for actual camera/object motion blur raytracing
but it's unfinished (it badly slows down the raytracing kernel even when the
option is turned off), so that code it disabled still.
Motion vector export from Blender tries to avoid computing derived meshes
when the mesh does not have a deforming modifier, and it also won't store
motion vectors for every vertex if only the object or camera is moving.
Sponsored by the Blender Development Fund.
http://www.blender.org/blenderorg/blender-foundation/development-fund/
Remarks:
The original code was not designed to support moving obstacles so I had to introduce some velocity constraints into the code to prevent smoke from exploding. If this causes problems with "fire" emulation, please let me know.
* Fix for [#31099] Audio in Meta-Strips Plays Beyond Strip Cut
* Adding a split files option to the mixdown operator which then renders each channel into a separate file
