Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addon Development
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Addon Development Developers post news, updates, & discussions here about your projects in development.

Reply
 
Thread Tools
Old 02-25-2014, 04:34 PM   #16
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

I now had the time to actually run and test it a bit. I like what's there of the handling. A few things:

An alternative to middle mouse button will be needed. A lot of laptops don't have one. I'll do this when I plug in the new event handler.

While the ability to rotate stuff the way you want it when docked, keep in mind that it is not possible in orbiter: The docking ports have a fixed alignement, and short of having the module save rotated port indices and new alignements in the scenario and apply them at loadup, the vessels will not appear as they are visible in the StackEditor. Such an approach would however conflict with any add-ons that rotate docking ports by themselves (like for example IMS).

I think it would be best to only allow docking to the actual orbiter docking port alignements to keep it as generally applicable as possible.

And yeah, something's fishy with that meshloader, it seems. Or the texture loader, rather.

Anyways, I managed to check out the develop branch, I'll start easy by plugging in a new eventhandler and see if I get that stuff with the commits...

Last edited by jedidia; 02-25-2014 at 04:36 PM.
jedidia is offline   Reply With Quote
Old 02-25-2014, 08:53 PM   #17
meson800
Donator
 
meson800's Avatar

Default

Quote:
Originally Posted by jedidia View Post
 An alternative to middle mouse button will be needed. A lot of laptops don't have one. I'll do this when I plug in the new event handler.
Thanks, I didn't think of that.

Quote:
Originally Posted by jedidia View Post
 While the ability to rotate stuff the way you want it when docked, keep in mind that it is not possible in orbiter: The docking ports have a fixed alignment, and short of having the module save rotated port indices and new alignments in the scenario and apply them at loadup, the vessels will not appear as they are visible in the StackEditor. Such an approach would however conflict with any add-ons that rotate docking ports by themselves (like for example IMS).

I think it would be best to only allow docking to the actual orbiter docking port alignements to keep it as generally applicable as possible.
That's because the modules don't actually dock when they snap together at the moment...

Inside the VesselSceneNode::snap code, I only have the first quaternion snap, which aligns it. I need to add the second quaternion which rotates the reference directions like they are in Orbiter.

Also, the rotation you see in the program occurs because the "docked" flag actually isn't set, I haven't gotten around to actually competing that section of the code. When they do "dock" together, a click on any of the stack vessels will move the entire stack. When I get time, I'll prioritize the above so it works more like it is supposed to.

Quote:
Originally Posted by jedidia View Post
 Anyways, I managed to check out the develop branch, I'll start easy by plugging in a new eventhandler and see if I get that stuff with the commits...
You might want to work off a topic branch off of develop. Just remember to push that branch to the server if you do do the topic branch.

Pushing a local branch to a remote branch (only do this once to create the branch on Github)
Code:
git push -u origin your_branch
On the crappy-looking IMS textures, do any of the modules include transparent textures? I think I might have to set a flag in Irrlicht to get it to render transparent.
meson800 is offline   Reply With Quote
Old 02-26-2014, 01:54 PM   #18
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

I doubt there are any transparent textures. I'm not even sure vanilla orbiter supports them. But greg wasn't really adept at using textures, doing most detail work in polies, so i would be very surprised if he used transparency.

On the topic of reworking the vesselscenenode: i'll have to make some major changes to the overall architecture to ensure an efficient workflow with the gui.

In explicit, i'll have to preload stuff (meshes and configs) before creation of vesselscenenode.
I'll make a mesh manager to ensure that every mesh is only loaded once, and the config data will be stored in a new vessel data class, from which later, when the user creates a vessel, the vesselscenenode will be created. This won't change too much in the present code (vesselscenenode will get a new constructor, that's about all), but there is one thing that has to change: the dockport and mesh data in vesselscenenode has to be switched to use pointers. I can do that when I get to it, but it would probably be best to do it sooner if there's a lot of code to be added to the class.

Also, take into account that at one point the program will need not only to know about the individual nodes, but also about the stack they are docked in. You should write the docking code with that in mind.
jedidia is offline   Reply With Quote
Old 02-26-2014, 02:41 PM   #19
meson800
Donator
 
meson800's Avatar

Default

Quote:
Originally Posted by jedidia View Post
 In explicit, i'll have to preload stuff (meshes and configs) before creation of vesselscenenode.
I'll make a mesh manager to ensure that every mesh is only loaded once, and the config data will be stored in a new vessel data class, from which later, when the user creates a vessel, the vesselscenenode will be created. This won't change too much in the present code (vesselscenenode will get a new constructor, that's about all), but there is one thing that has to change: the dockport and mesh data in vesselscenenode has to be switched to use pointers. I can do that when I get to it, but it would probably be best to do it sooner if there's a lot of code to be added to the class.

Also, take into account that at one point the program will need not only to know about the individual nodes, but also about the stack they are docked in. You should write the docking code with that in mind.
Preloading the meshes and config files is a good idea which I was moving towards, but it might be better if you wrote it to fit with your GUI idea.

I however do not see the advantage of storing pointers to the OrbiterDockingPorts. If each individual vesselscenenode has it's own OrbiterDockingPorts, it can directly store information (pointers to parent/docked node) about the vesselscenenodes it's attached to.

As to the stacks. I could easily add a vector<VesselSceneNode*> to store each stack. Do you think this will really help overall performance? When I initially envisioned this, I imagined stack information would be generated mostly on-the-fly.
In the current system, the plan was to, when a node was selected in the event receiver code, to recurse through the docking ports, adding each new vesselscenenode to a vector called something like SelectedStack. Then, any movement/rotations/copy&paste operations would just act on all of the VesselSceneNodes inside SelectedStack. This should work with the current system, and is not that bad efficiency-wise because the recursive function is only called once, when the user clicks on a node. Any subsequent operations just use the generated stack info.

In my envisioned system, docking would occur as follows, using a "dock" function inside VesselSceneNode:
  • Snap our docking port to the other node's docking port, just in case
  • Set the docked bool in our docking port and the other docking port
  • Set our docking port's "dockedTo" pointer to the other docking port's parent, and vice versa
Then, when stack information is re-generated when one of the nodes in the stack is selected, it automatically includes the new docked node.

Undocking is simply handled as setting each docked bool to false, and nulling the dockedTo pointers.

What was your idea regarding stacks? It seems more complicated than it's worth to store global stacks. In that case, one vesselscenenode could not simply dock itself to another, docking would be a more complicated procedure, involving the docking sequence above, but then pointers to VesselSceneNodes would have to be bumped around the various stacks.

I'm not sure when I'll be able to get back to programming, it might be a few days, but I'll focus on docking.
meson800 is offline   Reply With Quote
Old 02-27-2014, 02:10 PM   #20
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
but it might be better if you wrote it to fit with your GUI idea.
And I will. As I said, about the only change to vesselscenenode would a new constructor, which I'll implement once I need it, and switching the mesh to use a pointer. If the code you're going to add involves references to the mesh, it might be smarter to make that switch now, before a lot of new code is added that will have to be changed later on. If the switch to pointers will only affect the current code, then it doesn't matter.

Quote:
I however do not see the advantage of storing pointers to the OrbiterDockingPorts.
Sorry, I was unclear. I was merely refering to the data from which the ports are created, which is currently stored as a member of each vesselscenenode individually.

Quote:
I imagined stack information would be generated mostly on-the-fly.
That should work too, I guess. Just as long as we have the possibility of docking stack to stack. The advantage of having the stacks registered would be that they are easily selectable from a list, but I guess it would be more trouble than the feature is worth...
jedidia is offline   Reply With Quote
Old 02-27-2014, 09:13 PM   #21
meson800
Donator
 
meson800's Avatar

Default

Quote:
Originally Posted by jedidia View Post
 And I will. As I said, about the only change to vesselscenenode would a new constructor, which I'll implement once I need it, and switching the mesh to use a pointer. If the code you're going to add involves references to the mesh, it might be smarter to make that switch now, before a lot of new code is added that will have to be changed later on. If the switch to pointers will only affect the current code, then it doesn't matter.
Thanks

I just pushed the most recent revision which fixed a bug where material definitions would not be read correctly. IMS modules still display strangely, but other weirdly colored meshes (MIR) are now normal.
meson800 is offline   Reply With Quote
Thanked by:
Old 03-01-2014, 01:03 PM   #22
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

I finished the backend, that is the data manager and the changes to shipyard and vesselscenenode.

Now I'm going to try to put my GUI in front of it. It will be big and uggly for the beginning, using scenario editor images. I hope I can switch this to render the images directly to texture from the meshes, although I'm not actually quite sure if this can be done offscreen in Irrlicht...

---------- Post added at 02:03 PM ---------- Previous post was at 01:11 PM ----------

Whoopsa, I just noticed another slight problem: Helpers::ReadLine tokenises only for whitespace... note that a whitespace between the parameter name and the "=" in the configs is customary, but not mandatory.
Orbiter will accept input from a config file that is for example written like "MeshName=Ninuninu", while stackeditor currently does not.

I suggest expanding the ReadLine function with a parameter than can accept a custom character set to accept for tokenisation (well, I'm already doing it on my end, really... just so you know that I'm making a few changes there too).

In effect, putting whitespace and "=" in there will return a vector with only two tokens, the parameter name and the value, so it will affect quite a bit of code.
jedidia is offline   Reply With Quote
Old 03-01-2014, 07:39 PM   #23
meson800
Donator
 
meson800's Avatar

Default

Quote:
Originally Posted by jedidia View Post
 I finished the backend, that is the data manager and the changes to shipyard and vesselscenenode.
Can you push it, at least part of it if it is in a non-broken state? If we push/pull more, we'll make sure we aren't working on outdated code that someone else has fixed in the meantime.

Quote:
I hope I can switch this to render the images directly to texture from the meshes, although I'm not actually quite sure if this can be done offscreen in Irrlicht...
Actually, when I first envisioned this project, I was thinking of doing the same thing, rendering the images directly. You can easily create a new Irrlicht device and just call createScreenshot to generate a picture of each module. The question is whether you can create a hidden device that screenshots still work on. For example, I use a null device to find the screen size; it may be possible to use a null device to render the GUI pictures.

Quote:
I suggest expanding the ReadLine function with a parameter than can accept a custom character set to accept for tokenisation (well, I'm already doing it on my end, really... just so you know that I'm making a few changes there too).
Feel free to fix or improve anything. Nice catch on the whitespace. I would also watch out for things that occur in some meshes/configs that aren't "techincally" allowed in the Orbiter standard - for example, I had to fix the mesh loader, as I found a couple meshes which ommited normal coordinates without the NONORMAL flag, even though it should be illegal.
meson800 is offline   Reply With Quote
Old 03-04-2014, 01:52 PM   #24
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Fully functional GUI is in. I start thinking that pre-loading all the meshes might not be such a great Idea after all. The loading times are a killer.

I have created Toolboxes for IMS, using nothing but the GUI tools for creating and editing them. Here's how it works:

Select toolbox from the list at the left. Double-click on image to create vessel and position, repeat ad infinitum.

Edit toolboxes: Right-click on Toolbox area to bring up context menu (toolbar must have focus first, so if the menu doesn't appear click with the left button first... Wasn't yet able to figure out how to focus when pushing the right mouse button).

Add vessel opens the file dialog, and you can add new vessels to the toolbox. Dialog will stay open after adding until you close it, to make it easier to add several vessels.
Remove vessel removes the vessel from the toolbox where the right-click occured.
Create new toolbox brings up a naming dialog to create a completely new toolbox.

That's about that so far. The docking code needs lots of work as I found out when playing with more complex constructions. I'll have to think how to best handle the loading. You'll see that the loading times currently are abysmal... :/
jedidia is offline   Reply With Quote
Old 03-04-2014, 04:01 PM   #25
meson800
Donator
 
meson800's Avatar

Default

Thanks!

Again, I'll finish the docking code. I'm not sure when I'll be able to get time to program it, but I should be able to get to it some time in the next two weeks.

My plan for docking is any selected vessel selects the whole stack of vessels. Any operation (copy, move, rotate) operates on the whole stack.

Then, to undock vessels, the user would have to hit some button (shift?). When they press shift, the vessels are drawn partially-transparently, and the docking port nodes are displayed. In this mode, any clicks selects a docking port SceneNode instead of VesselSceneNodes. When a node is selected, that docking port is undocked.

The system isn't quite as slick as the KSP-way, where vessel stacks auto-undock, but KSP also locks construction into one axis (basically). We can't do that, so we'lll have to go with manual undocking.
meson800 is offline   Reply With Quote
Old 03-04-2014, 04:17 PM   #26
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
Again, I'll finish the docking code. I'm not sure when I'll be able to get time to program it, but I should be able to get to it some time in the next two weeks.
Sure, no hurry. I just had the first opportunity to really play around with it, what with the GUI needing testing

Quote:
Then, to undock vessels, the user would have to hit some button (shift?
Just make it a double-click (though, if I remember correctly, those will need a bit of tweaking when integrating into orbiter... I'll cross that bridge when I get there). The concept sounds solid.
jedidia is offline   Reply With Quote
Old 03-04-2014, 09:33 PM   #27
meson800
Donator
 
meson800's Avatar

Default

Quote:
Originally Posted by jedidia View Post
 Just make it a double-click (though, if I remember correctly, those will need a bit of tweaking when integrating into orbiter... I'll cross that bridge when I get there). The concept sounds solid.
Good idea on the double click.

Why will it be difficult to integrate into Orbiter? Irrlicht is independent of everything else, all we have to do to integrate into Orbiter is create a new "custom function", and call the "main" function when StackEditor is created. Then, StackEditor would pop up normally as it occurs now.

Obviously there would have to be some code to handle import/export to Orbiter, but that isn't that difficult.

Were you thinking that it should be live-editing of Orbiter vessels?

I imagined a simple import/export system. After the user activated StackEditor, the currently focused vessel/all docked vessels would be imported into StackEditor and Orbiter would be paused. After the user was finished with SE, they press "export", and the new docked vessels are imported back into Orbiter, the main SE window is closed, and Orbiter is unpaused.
meson800 is offline   Reply With Quote
Old 03-04-2014, 10:54 PM   #28
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
Why will it be difficult to integrate into Orbiter? Irrlicht is independent of everything else, all we have to do to integrate into Orbiter is create a new "custom function", and call the "main" function when StackEditor is created. Then, StackEditor would pop up normally as it occurs now.
Actually it will have to run in a child thread, or communication with Orbiter will get difficult, using protocols and stuff. But that's not the problem, we can run irrlicht in a child thread and let it render into a Dialog Box within orbiter. The problem is also not really a big problem:
The eventreceiver will have to receive the events from the orbiter thread though, so you have to post them manually (I have all the code for that ready, don't worry. With the structure as it currently is, it's really just a matter of switching out main.cpp). However, last time I did this trick, there was trouble with double clicks. For some reason the event didn't get posted, I had to create the event manually by measuring the time between two mouse clicks. Which was a bit easier then since I had one global eventhandler. With the event-handling architecture of StackEditor (which is perfectly well suited for its purposes with all nodes being able to receive their own events independantly), I'm not sure yet where to move the timer. Probably right where the events are posted from the orbiter thread. I'm sure it'll be solvable, that's just one problem I had with the implementation the last time I worked with it.


Quote:
I imagined a simple import/export system. After the user activated StackEditor, the currently focused vessel/all docked vessels would be imported into StackEditor and Orbiter would be paused. After the user was finished with SE, they press "export", and the new docked vessels are imported back into Orbiter, the main SE window is closed, and Orbiter is unpaused.
Interesting. I didn't think of that, but it seems like a straight forward enough solution. There's one (unimportant) detail: If you pause Orbiter you pause all child threads, so you'll have to leave the sim running, but the concept should still work splendidly.

Quote:
Were you thinking that it should be live-editing of Orbiter vessels?
Yes, I was. The reason for that is that I will probably adapt the code to make an IMS2 specific editor later on that directly communicates with the IMS2 vessels inside orbiter. With that goal in mind, it simply didn't occur to me that there is a much simpler solution for what we're trying to do currently (the import-export scheme you just suggested).
jedidia is offline   Reply With Quote
Old 03-05-2014, 01:19 AM   #29
meson800
Donator
 
meson800's Avatar

Default

Quote:
Originally Posted by jedidia View Post
 Actually it will have to run in a child thread, or communication with Orbiter will get difficult, using protocols and stuff. But that's not the problem, we can run irrlicht in a child thread and let it render into a Dialog Box within orbiter. The problem is also not really a big problem:
The eventreceiver will have to receive the events from the orbiter thread though, so you have to post them manually (I have all the code for that ready, don't worry. With the structure as it currently is, it's really just a matter of switching out main.cpp). However, last time I did this trick, there was trouble with double clicks. For some reason the event didn't get posted, I had to create the event manually by measuring the time between two mouse clicks. Which was a bit easier then since I had one global eventhandler. With the event-handling architecture of StackEditor (which is perfectly well suited for its purposes with all nodes being able to receive their own events independantly), I'm not sure yet where to move the timer. Probably right where the events are posted from the orbiter thread. I'm sure it'll be solvable, that's just one problem I had with the implementation the last time I worked with it.

Why complicate things?

Just let Irrlicht run in it's own window. I just whipped together a quick integration test (the relevant changes are here), and it works fine. Just go F4->custom->stackEditor


You'll have to do a git pull and then checkout the testOrbiterIntegration branch
Code:
git pull
git checkout -b testOrbiterIntegration origin/testOrbiterIntegration
As a side effect, it has my partially un-finished docking code. Also, for some reason the debugger really, really hates relative paths, so you'll have to start Orbiter manually and enable stackEditor's module.

If you just let Irrlicht make a new window, we don't have to modify any of the event handler code, nor worry about manually posting events or some of the issues you described above.

Right now, it just creates a new thread for SE and detaches it so Orbiter doesn't hang.

For future integration, we could just create a normal Orbiter module with some functions/members that SE could access. Then, we just manage multi-threading by protecting those members with CriticalSections. I imagine we would create some structs that represent docked vessels, and create a vector of these structs inside the Orbiter module. Any access to the vector is protected by CriticalSections. Then, the import function is as simple as pushing structs to the vector, and letting SE access them, then clear the vector, and the export function is as simple as having SE push structs to the vector, and the orbiter module access them and create the vessels.

As a note, let's continue developing StackEditor as a stand-alone executable at the moment (just continue working off of the develop branch, not testOrbiterIntegration), as it is easier to debug. This method of integration is simple, so we can just redo the integration when we reach a release-able point.

---------- Post added at 08:19 PM ---------- Previous post was at 07:42 PM ----------

As to the abysmal loading times, I think I have a solution. Due to the excellent way you have set up GetGlobalMesh, the solution is just to background load the meshes.

Basically, at load, split off another thread that continues to load meshes, so SE doesn't hang. Then, if the user selects a mesh that has not been background loaded, it just manually loads because of the design of GetGlobalMesh, and the user may see a slight unresponsiveness as the mesh loads. If the user selects a mesh that already has been background loaded, then it is created without any lag time.

The only caveat is that you have to again protect the vector with CriticalSections (basically just wrap all the code in GetGlobalMesh/GetGlobalConfig in the protection code), but that isn't that bad.

Last edited by meson800; 03-05-2014 at 12:47 AM.
meson800 is offline   Reply With Quote
Thanked by:
Old 03-05-2014, 08:19 AM   #30
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
If you just let Irrlicht make a new window, we don't have to modify any of the event handler code, nor worry about manually posting events or some of the issues you described above.
Why, I'll be darned... I never thought it would work to actually let irrlicht spawn its own window inside orbiter, I expected context conflicts... My implementation so far was to let irrlicht use the window spawned by orbiter as a rendering surface... It looks like I'm thinking too much out of the box, ignoring the obvious, simple way

Quote:
Basically, at load, split off another thread that continues to load meshes, so SE doesn't hang. Then, if the user selects a mesh that has not been background loaded, it just manually loads because of the design of GetGlobalMesh, and the user may see a slight unresponsiveness as the mesh loads. If the user selects a mesh that already has been background loaded, then it is created without any lag time.
There is a slight problem here... not pre-loading the meshes pretty much dumps the render-to-texture Idea, i.e. I'll have to stick with the scenario editor images. (I can scale them so they're not that big... can also make it user defined so everyone can have the cake he likes).
On the other hand, when I don't need the meshes preloaded for that, I might as well save memory and pre-load only configs and images, and only load meshes on demand when they are created the first time... Or do you think that would disrupt the workflow too much?

Last edited by jedidia; 03-05-2014 at 09:04 AM.
jedidia is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Addons > Addon Development

Tags
ims, project, shipyard


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 05:41 PM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.