Marcus Lindblom wrote:
The strategy we adopted in a similar project was to simply write the
data to disk somewhere (is >> ofstream("tmpfile")), then load it via
the loadfile(char*)-function.
I thought about this too, but in my case the files are all more then
100MB and in some cases over 250MB. The extra I/O of reading in and
writing out combined with the amount of temp disk space it would take
just doesn't work with such large files. :(
There is simply no simple way around this for external API's which
expect things to be on disk, when you provide them via streams loading
data from gzips/network/memory or rhubarb pies. (I've found rhubarb
pies to be an excellent generic object to reason about. But that's
just me. ;)
Agreed. To me this seems to be a potentially major downfall of the
current file loader design in OpenSG.
-Allen
Then again, I suppose you could hook into the OS and establish your
own filesystem, send the filename as something like
\\localhost\myshare, or \dev\myfile, intercept that call and feed the
stream data directly without bumping it to disk. But I think that's
definitely a very bad case of over-engineering. ;)
/Marcus
Allen Bierbaum wrote:
I still haven't come up with a solution to dynamically loading
loaders, but I have come across a new issue.
The loader I am writing is using an external proprietary API. ie. I
have no source code and no control of the API.
The issue I am facing is that the external API does not support
streams, it only supports loading from a file name as a char*. Since
it seems that the readFile API for osg::SceneFileType is deprecated,
I am at a little bit of a loss as to what to do. From what I
understand of the SceneFileType API it looks like the read method
takes 2 arguments: 1. istream of data 2. filename or extension. I
could just assume that the 2nd param will always contain the filename
and ignore the stream, but this seems a little fragile. I know that
this will definitely break support for gziped files since that uses
an ultra cool stream adapter, but will it break anything else in how
OpenSG assumes the file loaders work?
It seems that this would be something that others have probably faced
when interfacing with existing loader libraries (especially C-based
ones that would have no concept of streams). What have other people
done in this situation?
Thanks,
Allen
-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to
collaborate
online with coworkers and clients while avoiding the high cost of
travel and
communications. There is no equipment to buy and you can meet as
often as
you want. Try it
free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to
collaborate
online with coworkers and clients while avoiding the high cost of
travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it
free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
