Project Architect Development

[csanders]

I didn't realize needing to click "load base into Orbiter" was that inconvenient.

 

[n122vu]

I didn't realize needing to click "load base into Orbiter" was that inconvenient.

How inconvenient would it be to add code to save a backup of the existing current .cfg file before making any changes? Not very, I think.

Even better would be giving the user the choice to do so, and allow them to choose where to save it and what to call it, along with the option to merge changes into the existing file.

 

[Face]

I'd anyway incorporate a version control system into every development workflow. So the balancing of security - with an inappropriate backup system/setup - against convenience of working on the actual data files - instead of a shadow database - is indeed a weak argument.

 

[4throck]

....
OBM is incomplete enough to where you have to do certain things by hand ...
Accurate positioning and tile editing stand out the most.

Well, I've redone all of the default Orbiter bases with the help of OBM and there are problems, sure. But nothing serious.

Never had any trouble with positioning. And can't understand what's the problem with the tiles.

The only major issue I found is that some objects are not corrected for earth's curvature.


If you have infinite time, then sure, go for perfection.
But if takes years, it will be incompatible with the latest version of Orbiter, so you will have to fix it. At that point, its not perfect at all :thumbup:

 

[Loru]

For me OBM is really fine except 1 thing

1. it should remember meshes subfolders (everytime I want to add mesh I need to slide down for proper subfolder where I keep meshes for articular base - remembering last one would be great improvvement)

 

[csanders]

Well, I've redone all of the default Orbiter bases with the help of OBM and there are problems, sure. But nothing serious.

Never had any trouble with positioning. And can't understand what's the problem with the tiles.

The only major issue I found is that some objects are not corrected for earth's curvature.


If you have infinite time, then sure, go for perfection.
But if takes years, it will be incompatible with the latest version of Orbiter, so you will have to fix it. At that point, its not perfect at all :thumbup:

Thanks. You get it. I'm not going to spend all my time perfecting OBM. It's #12 on the hangar's "highest rated files", yet still only has a little over 3000 downloads.

Funny thing, it was just intended as just a program to download google earth tiles, but that turned out to be Intellectual Property infringement, so I had to highly restrict that to the point it wasn't better than public domain images, so for personal use one could reasonably claim "fair use." Of course that decision had people complaining they can't download lower than layer 4 or zoom out in the tile editor to download more.

It had some base making abilities as a bonus, but with it's primary function curtailed, it kind of expanded on that. From there, I wanted something that people who didn't want to learn how to edit config files could use to make a base.

If you edit config files, you're not OBM's intended audience.

If you don't, and you can't use OBM, then I guess I failed.

Although I tried to balance between the two. If one edits config files, and finds OBM useful, then maybe I struck a decent balance.

Let's expand on this balancing act, and to answer the question "How inconvenient would it be to add code to save a backup of the existing current .cfg file before making any changes?"

A lot of people have more than one version of Orbiter on their machine. Which version of orbiter on the machine should I use for that? Should I use the one I'm writing to now? Ok. Should that override the one from later? Now things are staring to get a little more complicated. Let's make two depositories for this situation. Now let's make a user interface that makes that possible that won't confuse the newby! Yeah, I can make a system so that's possible, but the programming labor vs average user usability is very little, when I can use that labor for other things.

Labor for things like reading the solar system configuration one has on their particular Orbiter setup. A lot of people have made custom ones. Then reverse engineering the tile system Orbiter uses for planets, so OBM can display those unique planet features within the editor.

How about when people add each runway and landing pad, each get a unique frequency. Even when one copy and pastes them, OBM knows not to copy the radio frequency. Pretty tedious for a person to do, but OBM does it so seamlessly, most will never notice.

I could go on, oh could I, but I was just trying to get the software out there...

 

[paddy2]

Some where along the line this seems to have become a lets knock OBM thread.
Let me state my position, I LOVE OBM. It has allowed me to expand my use of Orbiter and has added great enjoyment to the whole.

I think OBM has some short comings and that there is room for another design program. However this "program to be" is not even in its pre alpha stage, or even got a full list of objectives. OBM has to be better than any program not yet written!!!

To use this thread to knock OBM in no way enhances the design process so please folk can we put a stop to this.

 

[Face]

Let's expand on this balancing act, and to answer the question "How inconvenient would it be to add code to save a backup of the existing current .cfg file before making any changes?"

A lot of people have more than one version of Orbiter on their machine. Which version of orbiter on the machine should I use for that? Should I use the one I'm writing to now? Ok. Should that override the one from later? Now things are staring to get a little more complicated. Let's make two depositories for this situation. Now let's make a user interface that makes that possible that won't confuse the newby! Yeah, I can make a system so that's possible, but the programming labor vs average user usability is very little, when I can use that labor for other things.

Labor for things like reading the solar system configuration one has on their particular Orbiter setup. A lot of people have made custom ones. Then reverse engineering the tile system Orbiter uses for planets, so OBM can display those unique planet features within the editor.

Here you have 2 pretty good points why an integrated solution is straight forward IMHO:
1. No question about what Orbiter version to use... it is the one the program runs within.
2. No question about how to reverse engineer something or display the unique planet features... the renderer is already there.

I could go on, oh could I, but I was just trying to get the software out there...

I understand why you feel the urge to justify your design decisions, but I think they are wrongly placed here, as it is about a different goal: to create a new and much more complete solution for the base creation task.

However, IMHO this new solution will fail right from start if it takes the same approach previous solutions attempted: to go decoupled from Orbiter. Without constant and direct feedback from the Orbiter engine, every design work will be a shot in the dark, in the sense of needing repeated Orbiter tests to "get it right". The existence of OVP is not really helping here, either.
Using a different data model than Orbiter itself is just another symptom of this pitfall. Fear of long development periods "into" possible new Orbiter versions and/or custom solar systems, too.

I also think that a decoupled approach is actually more work than an integrated one. You will have to reverse engineer formats, write parsers, use graphics engines, test all that... for being at the very starting point of every Orbiter plugin. And if there really is a functionality that is not already there, why taking the time to create it in a different environment so it can't be re-used by the community?

That said, I totally understand the notion of not wanting to go outside the "programming comfort zone" of the OP here. However, my opinion is that years to come are better invested in learning C++ and Orbiter API instead of coding another decoupled base maker. This way everybody would benefit from the investment: the OP, because he can add another skill to his set; the community, because there is a novel and fully integrated tool; Orbiter's creator, because he could see where the shortcomings are and what core features would make sense (and gets the code right there!). Especially with a scope spanning years, I think language choice should not dictate the code architecture, but the other way around.

I'm not totally altruistic in all this, mind you. You might be aware of the Ascension Ultra project I'm involved with WHAP, where I've already developed certain classes for better base development. An integrated base creation tool could take advantage of these classes just as well, adding things like taxiways and animations to Orbiter's default set. So please take my thoughts with a grain of salt.

regards,
Face

 

[4throck]

...
That said, I totally understand the notion of not wanting to go outside the "programming comfort zone" of the OP here. ...
... I'm not totally altruistic in all this, mind you. ...

Nice ideas there. Since the OP mentioned web languages, those could be used to tap into the Open Street Maps database or have some sort of online base creator tool / scenery database.
Just floating ideas that might fit the OPs interests and still bring something new.

 

[Aev]

Okay wow, I just finished holiday traveling and it looks like i have a LOT of replying to do. Lets get to work then!

I will avoid involving myself in the above debate concerning Orbiter Base Maker. If you have any suggestions for features, I'll review those, but as I stated in my previous post, I respect and thank both ar81 and csanders for the programs they've created. Are there features and aspects in both applications I'd like to implement, modify, and configure? Absolutely. It's the reason why I began writing the program after Surface Base Wizard and why I continue to write it after tinkering with Orbiter Base Maker.

I'll primarily address Face's post since it's literally overflowing with common sense, presenting an ideology I happen to agree with.

...

I'd like to discuss the positive aspects of creating a rendering engine external to Orbiter, but any argument I'd formulate would be flawed. In my previous response addressed to you, I wrote that utilizing Orbiter's default engine would be far beyond my scope of knowledge, so any argument in support of an external renderer would be largely based on ignorance. I'd like to state that my own engine would make it easier to support features such as calculative objects and other non-object components within the viewport itself (as well as my own surface base file format that I can be used to save groups, labels, and non-object components), but it's quite possible that this isn't the case. So I must refrain from engaging in such a argument. Frankly, you're most likely correct in all your statements supporting integration and there might not be much to argue about.

So then why do I continue developing the program? It was a personal project I had planned, outlined, and begun writing years ago. Taking into consideration several other projects specifically with java, I decided to work on this one as a display of ability specifically with this programming language. Thus, despite the fact that I ultimately chose this project because I appreciate Orbiter and it's community, my reasons aren't purely altruistic either. With my current schedule, building an advanced understanding of c++ while maintaining fluency in java and other languages simply to build this editor will be an inconvenience. Face, this may disappoint you (or anger you even) but my own self confidence with Java is why I know I can deliver a quality product in the end.

Therefore, I'll continue development of the project with the goal of improving base design experience for both novice, casual, and advanced users.

...

I will return tomorrow to respond to previous posts or any subsequent responses within this thread. Having just arrived home after traveling, I have lots to do. Then I should be able to reply in intervals shorter than 24 hours :lol:

Regards!

 

[Face]

So then why do I continue developing the program? It was a personal project I had planned, outlined, and begun writing years ago. Taking into consideration several other projects specifically with java, I decided to work on this one as a display of ability specifically with this programming language. Thus, despite the fact that I ultimately chose this project because I appreciate Orbiter and it's community, my reasons aren't purely altruistic either. With my current schedule, building an advanced understanding of c++ while maintaining fluency in java and other languages simply to build this editor will be an inconvenience.

I doubt that somebody fluent in Java will have much problems with C++, but fair enough, I can see where you are coming from.

Face, this may disappoint you (or anger you even) but my own self confidence with Java is why I know I can deliver a quality product in the end.

No honest contribution to Orbiter can anger or disappoint me, even if it takes the wrong turn from my point of view. After all, it adds something to the community, and this I'll always applaud. Please don't take my postings as affront, but as an honest feedback to your call for comments.

Therefore, I'll continue development of the project with the goal of improving base design experience for both novice, casual, and advanced users.

Good luck with your project !

 

[Aev]

OBM stores the base data somewhere else, not in the base's configuration file. You must avoid this at all costs! If custom data must be written, write it as a comment into the configuration file.

I'd like some opinions concerning what I'm about to write from not only you, RisingFury, but from everyone.

As I planned it, any surface base configuration file can be opened from Architect, but to accommodate custom features, a separate output file was need. This file can be saved anywhere and can then be exported to the configuration file which Orbiter reads. For example, if any of you have used Photoshop or GIMP, they each have their own file formats (PSD for photoshop) which can then be converted to a jpg or a png file. In the event that constantly exporting the file is an inconvenience, I should be able to create a single button that generates a scenario file with the exported surface base in focus, and then runs Orbiter with that scenario.

This can be accomplished with: http://orbiter-forum.com/showthread.php?t=20249&highlight=orbiter+command+line (scroll to Martin's post)

Thoughts?

My only suggestion is not to redo OBM.
Concentrate on what OBM does not do, like taxiways and random/ordered placement of custom meshes/objects.
That would be useful.

Another interesting route would be to import data from Open Street Map for example.

As for 3D objects, you can search Orbiter Hangar and see what's there and contact the authors. A quick search turned up a radar dish: http://www.orbithangar.com/searchid.php?ID=3408

I must agree with RisingFury; my intentions weren't to create a tool to compliment OBM or SBW, but to create a complete product where most, if not all, of the work could be accomplished. OpenStreetMap is interesting and I'll reserve time to explore it, but it's not a priority at the moment. As for 3D objects in Orbithanger, it's a great idea and when the time comes, I may do just that.

And please write a program that does not require me to switch my locale from Germany-German to US-English for editing something. MeshWizard is alone a torture in that category.

Sounds reasonable. Noted :thumbup:

No honest contribution to Orbiter can anger or disappoint me, even if it takes the wrong turn from my point of view. After all, it adds something to the community, and this I'll always applaud. Please don't take my postings as affront, but as an honest feedback to your call for comments.
....
Good luck with your project !

I actually did enjoy reading your responses because they made me seriously think about the project in general. Thank you very much

...

There are two more comments in the thread I haven't addressed yet. I'm taking time to seriously think about them. Know that any suggestions I'm fond of are saved and stored locally along with the person who presented the idea. So when I express approval or say I'm "keeping something in mind", these aren't empty words.

Regards

 

[4throck]

If I may, let me suggest a "simple" feature that would be useful just by itself:

The ability to open a web mapping service, display an area and then draw lines over it. For each line you can select a width and a color/material.
You can then export those lines as a Orbiter mesh with appropriate scale.

An alternate implementation would be KML import :hmm:

That would be useful for taxiways, streets, and much more.
If you go the KML route, there's the possibility of defining areas. You could then generate random objects on those areas (rocks, trees, antennas...)

This is what I'd need to improve my bases, for example. Something that automates the process.

 

[RacerX]

something perhaps to keep in mind. If landsat is implemented http://www.orbiter-forum.com/showthread.php?t=32465&highlight=martins will height also have to be taken into consideration?

 

[n122vu]

Question, and maybe I'm way off-base here (no pun intended), but why has no one tried integrating this functionality into the scenario editor? The source code is included with the installation.

I realize the scenario editor currently just stores .scn files, but why not add to that plugin, say, a separate set of pages that creates, modifies, and saves bases on the fly when you click OK on that particular page? The plugin already contains the controls and code for positioning objects at selected bases on the ground. Why not build upon what is already there?

 

[Aev]

At this time, a lot of the core work is done; some attention can now be redirected to io and gui development. I'll post biweekly blog development logs for anyone wanting to know the status and progress. They will start on the 11th or the 12th of January.

As I planned it, any surface base configuration file can be opened from Architect, but to accommodate custom features, a separate output file was need. This file can be saved anywhere and can then be exported to the configuration file which Orbiter reads.

I may retract what I wrote here. I took some time to experiment and I think I should be able to just save custom data in the surface base cfg file after all. Supporting one specific feature lead to my previous response above, but I hadn't considered all options. Doing things this way should please a lot of people.

something perhaps to keep in mind. If landsat is implemented http://www.orbiter-forum.com/showthr...hlight=martins will height also have to be taken into consideration?

I'll be monitoring progress with this closely. When the next official release of Orbiter is produced, then I'll make it a big priority to do what I can concerning terrain editing. Assuming I've read everything, we haven't been given details concerning how a user could alter the terrain. I'll patiently await that information

If I may, let me suggest a "simple" feature that would be useful just by itself:

The ability to open a web mapping service, display an area and then draw lines over it. For each line you can select a width and a color/material.
You can then export those lines as a Orbiter mesh with appropriate scale.

An alternate implementation would be KML import

That would be useful for taxiways, streets, and much more.
If you go the KML route, there's the possibility of defining areas. You could then generate random objects on those areas (rocks, trees, antennas...)

This is what I'd need to improve my bases, for example. Something that automates the process.

I'll reserve time to explore this, but in no way is it a priority, nor am I officially saying that I'll support it. It's currently at the very bottom of my todo list.

Question, and maybe I'm way off-base here (no pun intended), but why has no one tried integrating this functionality into the scenario editor? The source code is included with the installation.

I realize the scenario editor currently just stores .scn files, but why not add to that plugin, say, a separate set of pages that creates, modifies, and saves bases on the fly when you click OK on that particular page? The plugin already contains the controls and code for positioning objects at selected bases on the ground. Why not build upon what is already there?

There is a major unintended communication issue between the community and myself. In no way am I blaming anyone; the fault is mine. You see, I have very detailed idea of what I want to accomplish and unfortunately, members of the community cannot read my mind. For all that I want to develop, using the scenario editor (as I envision it) would be an interface nightmare. In addition I think it would vastly limit functionality and capability. My first blog post next week will address the gui and interface and perhaps this will shed some light on my reasoning for writing this.

Furthermore, your post somewhat brings forth concerns Face posted earlier. Unfortunately, expanding the scenario editor is beyond my knowledge (being a java programmer). If another developer decides to step forward and develop integrated surface base editing within Orbiter itself, I will provide as much support as I'm able to, harboring absolutely no feelings of disdain or anger. However, I will continue this project either way for personal satisfaction and to meet my planned goals for university and for life.

 

[RisingFury]

I'm glad to see you working on this project and that you're writing everything directly into the CFG file. Makes it much easier to make changes by hand

 

[4throck]

Here's an example of what can be done using the OpenStreetMaps data:
http://map.f4-group.com/#lat=28.4619109&lon=-80.5361931&zoom=16

Display the 3D map on that site and you will see trees, fences, generic building shapes, all generated from the available data...

 

[Phoenix]

A few ideas.

It'd be great to see taxiways using bezier curves and radiused corners at intersections with runways, aprons and other taxiways. It would also be a nice feature to have configurable runway markings, similar/better to what I did with my Configurable Runway System addon: [ame="http://www.orbithangar.com/searchid.php?ID=5863"]Configurable Runway System[/ame].

I am not sure how the future version of Orbiter intends drawing runways when terrain is taken into account, but would it be possible to render taxiways, runways, airfield grass and other surface-flush features directly onto surface base tiles? These tiles would conform to local elevations.

Good luck with your project.

 

[4throck]

Also don't know about the future Orbiter terrain engine, but in FlightSim they use a ground exclusion area, meaning that the terrain under the base is flat (but set to the appropriate general elevation).

So I wouldn't worry about it. Simply add a global Z offset to the base. For individual objects the parameter is already there and it works OK.