Dirk Reiners said the following on 11/02/06 21:27: > Hi Jan, hi dirk and all,
>> - minor nitpick: why are all the string arguments passed as const Char8*?
>> wouldn't const std::string& be the better choice?
>
> Absolutely. It's something that I've been wanting to change but haven't
> gotten around to. Patches welcome. ;)
after minor thinking i guess char* do have a merit. boost::tokenizer f.ex.
uses them in the separator description. i think before applying such a
heavy change the cost of repeatedly constructing empty (and not so empty)
std::string's should be investigated; or perhaps someone already did?
>> for those interested i've attached a (na\"ive) implementation for .trans.
>
> thanks for your prototype, but personally I was thinking about going
> another route.
>
> The whole pseudo-loader idea seems a little backwards. Given that we
> have GraphOps anyway, I was more thinking of making trans a GraphOp, and
> handling everything in SceneFileHandler.
>
> To do that you would have to extend getFileType() to find the actual
> file extensions and construct the GraphOpSeq at the same time (just
> constructing the string with a little format changing should be enough,
> or you can add another version of GraphOpSeq::setGraphOps that
> understands the format). If it's "" read() should use the passed in one.
>
> To support Simon's naming scheme you would also have to extend
> GraphOp::ParamSet::ParamSet to use ',' as an argument separator (right
> now it only does ' ').
>
> That should cover everything fairly nicely. Now the question is how to
> write a GraphOp. ;) Until I (or somebody else) write some documentation
> about it, I would use the VerifyGeoGraphOp as an example for a simple one.
>
> Comments?
mmh, the beauty of what the performer people did was that their pseudo-loader
scheme fit very nicely in the existing loader framework. there no distinction
is made between a traversing pseudo-loader (e.g. converting from one geo-rep
to another for a given sub-graph) and an inserting one (e.g. adding an xform
on top of the loaded scene) or a loader that just loads and converts a file.
plus, the generic loadFile interface can be called repeatedly and even
recursively.
i also see that this puts a "heavy burden" on each single loader implementation
by being required to check file existence, opening, seeking, and closing. it's
nice that SceneFileHandler takes something here off the shoulder of both the
library implementor and the application developer.
what i would like to be able to achieve here could be called separation of
concern. as long as i'm in control of the source and also knowledgeable of
the structure of an application i can probably live with SceneFileHandler and
GraphOps as they are. in the instant where i try to experiment with certain
inputs (or worse are stuck with some student hack that my boss absolutely wants
to show to some suit) i do want to have a fine grained control from the outside
(i.e. the commandline or shell) about what is happening to whom and when. taken
a step further i can imagine that when using this in a larger framework where
a prescribed application paradigm is set and i, as a developer, am only able
to fill in certain bits there are two choices:
1. do as the framework gods suggest and load everything, maybe several times
hoping that some magic (e.g. graphops) may help in optimizing; or
invest some extra time and effort to code a sequence of what i want to
do
2. have controlling support from a lower-level layer (opensg's scene-file
handler in that case) for describing a variety of parameters to be
temporarily associated with a given (scene-)file.
to make 2. happen within the current loader structure would mean a two-class
citizen system in opensg right now (including 2.0). the loader proper receiving
a stream they scan and convert into a scene graph. and the pseudo-loaders that
will have to be parsed off by whom? the SceneFileHandler or (also possible) some
callback function provided by the application. i think the easier way of
handling
this is by requiring only the minimal interface on the loader implementation:
NodePtr someLoader::loadFile(std::string const&);
bool someLoader::storeFile(NodePtr);
(yes, i deliberately choose the performer names here) ScenFileHandler then
should provide infrastructure that helps in path and file handling across
operating systems etc. with that graphops, xform-node-adding, and other things
can be supported without having the user to add code. orthogonal to that the
application developer is still free to add whatever traversal s/he sees fit
to make the application behave the way its supposed to. just off the top of my
head it could be sth. like a file name adapter that is capable of dissect a
given file name for "meta information" before handing the real file name (or
url) over to the actual loading mechanism, e.g.
SceneFileAdapter sfa(argv[1]);
sfa.addChild(SceneFileHandler::the()->read(sfa.realName());
sfa.apply();
NodePtr scene(Node::create);
scene->setCore(Group::create());
scene->addChild(sfa.getNode());
note, this still requires a two-class citizen implementation, loaders proper
for SceneFileHandler and pseudo-loaders (having probably different interfaces)
for SceneFileAdapter.
so, if you made it to this point, congratulations. i do not want this to be
perceived as a rant. i do want to have the "better scene graph api" and i
think opensg it is, for various reasons. but i also want to keep some things
that i found fexibility enabling in the past, so i'm up arguing that they
should be possible in the scene graph of my choice.
that's bit more than EUR 0.02 but what i wanted to say,
j.
--
+------------------------------------+--------------------------------------+
| jan p. springer | [EMAIL PROTECTED] |
| computer science, buw.media.vrsys | [EMAIL PROTECTED] |
+------------------------------------+--------------------------------------+
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
