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.
Thanks Lockal for finding faulty stat function which helped a lot.
Now there BLI_stat. I will replace all other stat later.
*** Please use BLI_xxxx() functions ***
for file operations
Reported by Leon Cheung, Lockal, Believil
* Fix word selection for words with multibyte characters. No need to call txt_move_left() or txt_move_right(), because these functions work with symbols, not bytes
* Word selection now treats tabs the same way as spaces. Also useful for words with multibyte characters
- makes wireframe from faces.
- options similar to inset (even offset, relative scale)
- copies face settings and loops (uvs, vcolors)
- optionally replaces the existing geometry.
- memset(..., 1.0); // isnt valid
- memset(pointer, sizeof(pointer)) // was using the sizeof the pointer, not the size of the array, since this was to fill in alpha values it was obviously wrong.
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/ray_linn/GCC-4.7.0-with-ada/mingw-w64-gcc-4.7.0-runtime-2.0.1-static-ada-20120330.7z/download
Other builds may also work but due to the constantly changing nature of the compiler this cannot be guaranteed. I often had to change compilers while building the libraries and this one is the one that did the job for most of them.
This first support is experimental and considered "advanced". To enable pass -DWITH_MINGW64 during cmake configuration. Also make sure to extract the compiler on C:/MinGW and that MinGW/bin is in your path. To build check out lib/mingw64.
Initially the support is lacking until I get every library compiled correctly. For now you should disable WITH_CYCLES(sorry, I know some people are dying to do benchmarks, but still a few libs to go), WITH_IMAGE_OPENEXR, WITH_OPENCOLLADA, WITH_LIBMV and WITH_CODEC_FFMPEG(links but hangs on startup).
Still the tools are working, the memory limit is increased and due to the experimental nature of the setup, full optimization with SSE2 is available, which makes the build quite fast. Also the compiler and especially, the linker are way faster than regular MinGW.
The wiki docs have also updated. Happy testing!
That whole "element re-arrange" area could use some love, though (e.g. make a single vert operator with more options, as faces; and make faces work in edit mode, probably no more reasons to switch to object mode?). Post-release TODO, anyway.
Also spotted a glitch in BLI_rand code, imho, which makes first element of an array not guarantied to be shuffled by BLI_array_randomize()... No correction though, as this might/would affect other parts of the code!
The cause for this is bmesh faces which have zero area have their normals set to a fake value (Z-Up), this would break scanfill, possible fixes are to calculate the faces normal each time or tag as invalid but its easiest to avoid the eternal loop with an extra test.