OpenVSP Background or custom views

[Allie Gonzales]

Hello,

Are custom views saved with the file? I know backgrounds aren't but I can't seem to load custom views after closing. I also tried to link camera movement in parm link, and it does so successfully(you can drive the camera with a user parm) but the link also seems to disappear after closing and loading. Is it a limitation or a bug?

thanks,

Allie

[Brandon Litherland]

Sorry this took a while to respond to.

The custom views that you can save using Shift + F1/F2/F3/F4 are not saved with the file nor are the backgrounds. View settings seem to re-initialize with new ID strings with each instance.  In fact, if you save a model and create a DES file with those camera settings and then close and load the model, you can bring those parm values in to the Design Variable window but they don't do anything.  The names are the same but the IDs have changed.  Perhaps this is something we can look into making a more "fixed" parameter.  In the meantime, I recommend taking a screenshot so you know what the camera angles and position look like so you can recreate those settings manually.

[Allie Gonzales]

Hi,

Thanks for the response! I will make that part of my current workflow. I look forward to the current system being updated but understand if it's not a priority.

All the best,

Allie

[Brandon Litherland]

So I take back what I said before.  I was incorrect about the Parm IDs being overwritten.  Per Edward's post linked below, the Adjust View GUI must be open for those parameters to be "live".  I've no idea why this is.

However, you may use either the DES file approach where you save each view as a separate Design Variables file or (an I think much better) you may simply set up Variable Presets with the relevant view settings saved as Group = Camera (or whatever) and Setting = View_1 (again arbitrary).  This way, you may save as many custom views as you like to the model.  Now to make this model file agnostic, you'll likely have to set up a script (again see Edward's post) which finds the vehicle ID and then changes the named parms to what you want.  The upshot of this approach is that you can use the same custom view (and zoom/scale) for any VSP model you like.

Sorry about the confusion!

Per Edward's post:

https://groups.google.com/g/openvsp/c/-79CfY1n9yA/m/IjNI7B3CCgAJ

[Rob McDonald]

I'm not sure why that window has to be open.  Probably connected to the faster update bugs -- if someone could try a version about three revs back, it would be nice to confirm.

Included with the OpenVSP zip is an example script testanimate.vspscript that demonstrates changing view points and automating screen shots in order to build up frames for an animation.  The easiest way to run it is from OpenVSP in graphical mode from the File.. Run Script...  menu.

If you want to generate images in a design process -- perhaps a DOE, or maybe you want to watch your vehicle evolve through an optimization process -- I recommend you don't use screen shots.  Instead, I suggest you dump out SVG for 2D drawings or STL for 3D (or some other format).  Then, set up your system with an easy way to visualize those formats.  For example, ModelCenter has a built-in STL viewer, so it can easily render a 3D model as a design process executes.

Rob

--
You received this message because you are subscribed to the Google Groups "OpenVSP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/dfa005da-2be5-4cb1-9707-699d7bca6edan%40googlegroups.com.

[jvgr...@gmail.com]

Rob,

I just replied to Edward's post Brandon linked above. Unless I'm overlooking specific API functions to support this, the problem is that the Parms in the ManageViewScreen can't be set unless the screen is open. These are view settings such as center of rotation, viewport size, zoom, and XYZ rotations. The "testanimate.vspscript" example is a great one to demonstrate the ScreenGrab capability, but does not include manipulation of the Parms in ManageViewScreen. I believe if we move the Parms and Update function to something like a "ViewMgr" in geom_core, everything should be able to be set and updated without the GUI or Adjust View screen being open. 

Thanks,

Justin

[jvgr...@gmail.com]

Correction: the example script "testanimate.vspscript" does include modifications to the Adjust View parms, but these won't be found if the script is run from the command line. 

-Justin

[Rob McDonald]

testanimate.vspscript does modify these parms...

    string veh = FindContainer( "Vehicle", 0 );                     // Find Vehicle container

    string panx = FindParm( veh, "PanX", "AdjustView" );            // Find view Parms in Vehicle
    string pany = FindParm( veh, "PanY", "AdjustView" );
    string zoom = FindParm( veh, "Zoom", "AdjustView" );
    string rotx = FindParm( veh, "RotationX", "AdjustView" );
    string roty = FindParm( veh, "RotationY", "AdjustView" );
    string rotz = FindParm( veh, "RotationZ", "AdjustView" );

I think you'll find that the AdjustViewScreen (or whatever it is) has a ParmChanged that does some magic tricks...

The underlying problem is that 'normal' mouse pan/zoom/rotate commands set the view quaternion deep in the graphics subsystem without using Parms along the way.  That quaternion becomes the authoritative view state.

Part of the problem is that the quaternion only exists in a graphics build -- so geom_core should not even know about it.

We don't want to make Parms the authoritative home for this state because the normal Parm update process is relatively slow for pan/zoom/rotate operations.  Instead, those are currently handled by updating the view transformation matrix on the graphics card and simply re-rendering.  No geometry update is needed, no lofting, no creation of DrawObj, no passing large amounts of data to the graphics card.

The only way for geom_core to communicate with vsp_graphics is through message passing.  Since updating the graphics through Parms does not need to be super fast, perhaps we can send a special message when just those Parms are updated.  Reverse communication is also a problem -- when someone rotates the model, you want the view Parms to be updated.  Right now, that back communication is not done.  Another thing the ViewEditScreen is taking care of...

This is more of an onion than you might think...

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/f57248d6-0e43-4c9d-9898-59ddab6eb96cn%40googlegroups.com.