|
From: Braden M. <br...@en...> - 2010-03-30 04:45:49
|
On Fri, 2010-03-26 at 08:48 -0700, cheribhai wrote:
>
>
> Hello,
> A couple of questions concerning change in viewpoint.
> (1) The VRML97 spec says that 'The jump field specifies whether the user's
> view "jumps" to the position and orientation of a bound Viewpoint node or
> remains unchanged.'
> The way I see it, if jump is true the viewpoint user view transform should
> by set to identity, which the following code does.
>
> void openvrml_node_vrml97::viewpoint_node::bind(const bool val,
> const double timestamp)
> OPENVRML_THROW1(std::bad_alloc)
> {
> this->is_bound_.value(val);
> last_user_view_transform_ = user_view_transform_;
> if(this->jump_.value())
> this->user_view_transform_ = openvrml::make_mat4f();
> node::emit_event(this->is_bound_emitter_, timestamp);
> }
>
> Am I right on this?
Yes, I think that looks good.
I thought I remembered getting this stuff working. I was certainly
thinking about it when I wrote the user_view_transform stuff; maybe I
just didn't quite finish the idea.
> (2) I am trying to implement viewpoint change animation in a custom browser.
> For this it seems that I need the attribute value of
> viewpoint_metatype::bind function to be set to visible (OPENVRML_API).
>
> Is this the way to go about what I want to do or is there another way around
> this?
Well, it's not going to be that simple. viewpoint_metatype lives in a
dynamically loaded module; it's not something you'd link against.
Is openvrml_node_vrml97::viewpoint_node::is_bound_ what you really want?
Of course, openvrml_node_vrml97::viewpoint_node lives in the same
dynamically loaded module; but in this case, it's not to hard to expose
functionality by pushing it up to the openvrml::viewpoint_node
interface.
There was a time that I was trying to avoid committing the libopenvrml
interface to the bindable node stack concepts; I was hoping that X3D
would evolve away from that brain damage. But it didn't. So there's a
compelling argument to be made that there's no point in continuing to
run from this.
--
Braden McDaniel <br...@en...>
|