supports compressing the image data. The option to compress the data
is "compressImageData". Currently it uses the jpeg plugin to write the
image. Maybe we could add an option that allows the user to specify
which image format to use. The jpeg writer supports specifying the
quality of the jpeg, so you could use the following command line to
convert the skydome.osg model to IVE using 50% jpeg quality:
osgconv -O "compressImageData JPEG_QUALITY 50" skydome.osg skydome.ive"
of saving image files inside the IVE file. Currently, only the raw
image data is saved into the file. If your model uses jpg images as
textures then this will cause your file size to increase.
I've added an option that will embed the original image file into the
IVE file. The IVE file will then attempt to read the image from
memory. Since most image loaders support reading from memory, this
shouldn't be a problem. To use this new feature the user must specify
the option "includeImageFileInIVEFile" when converting to IVE.
I tested this out on the "skydome.osg" model that comes with OSG.
Using the old method, the IVE file size would be 785 KB, with the new
method it is only 42 KB.
Also, I've added the support for TextureRectangle's to the IVE reader/writer."
an invalid bounding sphere if it hasn't seen a cull traversal yet. It
depends on _firstTimeToSetEyePoint, which is initially true, then false
after a cull. There might be a better way? If so, let me know.
This change does resolve the issue I had encountered with auto scale to
screen and incorrect culling."
FrameBufferObject.cpp there is also another fix: when initializing a FBO
attachment from a CameraNode attachment, the renderbuffer's format must be
set to the attachment's internal format, not to the image's pixel format.
Another problem is that attaching a renderbuffer to the FBO through
CameraNode is not simple (if not impossible) if you don't intend to specify
an Image object. Probably CameraNode could be enriched with an
"attach(buffer, width, height, format)" method. For example if you attach a
color buffer as a texture whose size is different than that of the
CameraNode's viewport you also need to attach a depth buffer of the same
size, because the depth buffer that is automatically attached by RenderStage
has the viewport's size. FBOs require that all attachment have the same
dimensions, so said setup will fail if you can't specify a custom depth
renderbuffer"
