Features:
All the good things you are used to
Manual
Test-model
Bug Fixes:
Installer now specifies “run in” directory -no more fiddling with shortcuts.
XML library is faster
Features:
All the good things you are used to
Manual
Test-model
Bug Fixes:
Installer now specifies “run in” directory -no more fiddling with shortcuts.
XML library is faster
Download it here: (PDF)
Features:
Bug-Fixes:
My little test-group have been experienceing a lot of scaling problems when exporting from 3Dmax;
My GUI made it possible to rescale models quite easily before launch, but this was too hasselsome.
One of the main features I’ve gotten requests for is a verifiable 1:1 scaling.
-This by both architects and industrial design students.
After searching a bit on the osgART forum, I found out that the problem was this line:
modelScale.makeScale(sizeModel/bound.radius(),sizeModel/bound.radius(),sizeModel/bound.radius());
Apparently it makes the scale relative to a bounding-sphere, that has a variable size depending on the extents of the modelspace before export.
By reducing the sizeModel/bound.radius to sizeModel/100, i now have perfect scaleing in percentage, as long as the model is exported in units. Preferably set to mm.
In the same post on the osgART forum’ a user was also having another problem I’ve been experienceing.
When I export models in 1:1, no matter where in the grid they are placed, they do not always stay in their exported positions on the z-plane.
Turns out, once again this was due to the bounding-box;
modelTranslate.makeTranslate(-bound.center());
This automatically centered the model on the unitTransform in ARive. Since the center of a model is not at the level of the plane, the entire model is translated down -making rescaling difficult, since for every step in %-scaling, one had to move the model (seemingly on hunch) up or down the Z-axis.
The solution was to do the translation as follows:
modelTranslate.makeTranslate(-bound.center.x(), -bound.center.y(), 0);
Now everything should work out fine, and all objects should scale “upwards” from their base on the marker, making it easy to i.e. scale a building whithout seeing it move downward through the groundplane.
More bugs have been fixed, and the whole thing should run a bit smoother.
Also a lot of input I’ve got from VisKom has been implemented better (OK/CANCEL-button conventions et.c.)
I want to make ARive as good as can be, but within the time-limits of the semester.
Thus, I’ll try to develop the software in stages of completion, so that I can stop implementing new features if I run out of time.
ARive BETA 1: (Status Quo)
Criteria:
A working executable
Marker tracking
Custom Markers (within design parameters)
Video display
Rendering:
support for textures: tiff, jpg, gif, png
support for baked maps
support for cube-maps
support for omni and directional lights (dynamic)
support for animation
support for particle-systems (some, simple)
….
3D-formats:
.osg (OpenSceneGraph native ASCII)
.ive (OpenSceneGraphnative binary)
Via converter:
.3ds
.obj
.pfb
…
Direct export from 3DMax 9
Geometry
Splines
Particle systems (some)
Animation
Textures
…
High Quality Performance
Support for low-end devices
Console-level loading (commands via prompt)
ARive BETA 2: Next step
Geometry Occlusion
Arive Beta 3:
XML-loading via parser (TinyXML?)
Branching of ARive into two executables
“ARiveB3.exe” <- normal edition,user defined lights
“ARiveB3-shadow.exe” <- real-time simulated shadows using object occlusion. Ideally parametrically controlled via XML/Max
ARive BETA 4:
Graphical Interface:
Stage 1:
Creates loading-scripts
Stage 2:
Creates XML-files for parsing togeather with loading scritps.
Stage 3:
Creates an index of stored XML-scripts that can be run at convenience
ARive BETA 5:
msi-installer
ARive RC1 -
Test with fellow-students
ARive 1.0 Champagne.