Hardware Need Assistance porting orbiter to SGI IRIX

[doctor_of_physics]

Hello Everyone,

Has anyone tried porting Orbiter to run on SGI hardware such as an Octane 2 or Fuel? Maybe even an Onyx or Tezro? These workstations and servers run an operating system called IRIX and they utilize a MIPS processor for those of you who are not familiar.

I just wanted to ask to see if anyone in the community has worked on this or if it is even possible. I will have a look to see what source code is available. I was also wondering if anyone has attempted to port to Linux as well. Please share your ideas and let me know if it is possible.
Truly,
Dr. Jim

 

[orb]

There is no source code available as Orbiter's core is closed source.

To run Orbiter on MIPS/IRIX you need an x86 emulator (e.g. BOCHS) with Windows installed on it.

 

[Urwumpe]

Also, Orbiter's add-on API is highly x86/Windows specific, porting it as black box just by the external interfaces will a pretty difficult work.

 

[doctor_of_physics]

Hello,
Thanks for letting me know this. I wasn't sure if it was open source or closed source. That clears that up. Do you think the Orbiter programming team would be willing to undertake such a task? It would open the simulator up to running on massively parallel systems via NUMA Link and CRAY link on the SGI side and Infiniband on the SGI and PC side. Not to mention that if they would port the simulator to the SGI platform it could take advantage of the ultra high end graphics cards like V10 and V12 graphics. The texturing and rendering is real time. It is older hardware but it's still incredibly fast. I'm simulating with a workstation with a Quadro 6000 card with 6GB of RAM right now and it's truly amazing. I guess I should ask how to contact the Orbiter development team and I wanted to know if it is possible to simulate with others over a LAN or WAN connection. I guess you could call it "multiplayer" even though Orbiter is not a game it's a simulator. Let me know your thoughts and thanks for responding.

 

[Urwumpe]

It would open the simulator up to running on massively parallel systems via NUMA Link and CRAY link on the SGI side and Infiniband on the SGI and PC side.

It wouldn't. You can't make a single threaded application run parallel by just letting it run on a multicore system. You need completely new algorithms.

Orbiter does right now not even support OpenMP.

(And hasn't IRIX been obsolete already in 2000?)

 

[doctor_of_physics]

Thanks for responding. I was thinking that support for OpenMP could be developed and the same for SMP support. Yes, sadly, IRIX was dropped along with SGI'S MIPS line of workstations and servers in 07-08 when the switched away from MIPS to IA64. I'm running the last release 6.5.30 It was a sad day when they dropped the MIPS line.

---------- Post added at 14:19 UTC ---------- Previous post was at 14:17 UTC ----------

I guess I'm thinking more toward running massive NBODY simulations and other cosmological simulations when it comes to needing big irons.

 

[Urwumpe]

I guess I'm thinking more toward running massive NBODY simulations and other cosmological simulations when it comes to needing big irons.

Yes, but those are not real-time simulations.

Of course, Orbiter could be developed for more performance like distributed rendering etc.

But why? Orbiter is not Paraview. Right now, it does a great job, just some few things require background workers (and are already done that way)

 

[doctor_of_physics]

I've been playing with Orbiter since 2006 and have been very impressed with every aspect of the program including the attention to detail, it's ability to simulate many aspects (if not all) of gravitational attractions, perturbations, velocity calculations, etc. We have truly come so very far.

I have two doctorates, one in physics and another in electrical engineering and computer science(I'm not egotistical or narcissistic, I'm only stating it for the record) I built my first computer at age 7 I am severely physically disabled and went to private schools so I was lucky enough to graduate at 16 and go straight away to college. My point being that I'm still amazed at how far we have advanced in our technology.

I remember when 5.25 floppy drives had a "huge" capacity of 1.2 MB and I was drooling over a 10 MB MFM hard drive. Now 300 GB isn't large enough lol. I would love to learn how to run simulations in Orbiter and write mods(I can write in FORTRAN, C, C++, C# and a couple of others).

Is there a way to have a "co-pilot" or for me to be the "co-pilot" and learn from a more advanced user? I have seen where Orbiter supports simulation over the network(multiplayer). Does Orbiter have that capability and is there anyone who could teach me more?

I am rather young and stuck in the bed all of the time do to my disabilities. Any help would be appreciated.
Thanks

 

[Face]

Is there a way to have a "co-pilot" or for me to be the "co-pilot" and learn from a more advanced user? I have seen where Orbiter supports simulation over the network(multiplayer). Does Orbiter have that capability and is there anyone who could teach me more?

Orbiter does not have that capability. There is no multiplayer feature in Orbiter yet.

 

[garyw]

I guess I'm thinking more toward running massive NBODY simulations and other cosmological simulations when it comes to needing big irons.

Why wouldn't you use software designed for the job?

Isn't that exactly what STK is for? http://www.agi.com/default.aspx

 

[doctor_of_physics]

Hello,
Yes, STK and Treecode are good and there are many others. I didn't relay my thoughts correctly. I wasn't planning on using Orbiter for NBODY calculations and simulations. What I meant was model complexity and the physics calculations that Orbiter performs brings the bigger systems to mind.
Thanks for the link. It's been a while since I've looked at their website.

 

[doctor_of_physics]

Yes, but those are not real-time simulations.

Of course, Orbiter could be developed for more performance like distributed rendering etc.

But why? Orbiter is not Paraview. Right now, it does a great job, just some few things require background workers (and are already done that way)

I agree, I've watched Orbiter evolve over the years (since 2006-2007 when I was informed about the simulator by a colleague). Even in the 200x release it had awesome graphics and now it is stunning even without the high resolution texture addons. I guess I was just throwing an idea out there. I'm still rendering on a SGI Onyx 3(64 R16000 700MHz CPUs) with IR3 graphics but that's reserved for massive data sets that need to be rendered and at that it can take days depending on the complexity and size of what I'm visualizing (some data is several Terabytes) but for everyday use I have a Fuel with a single R16000 700MHz CPU and V12 graphics and a HP Z800 series with, 64GB RAM, 2 quad core CPUs and dual NVIDIA Quadro 6000 graphics cards with 6GB RAM per card. I really haven't an idea as to how much of the Z800s resources Orbiter is utilizing since it's single threaded I know it's not utilizing much compute power but I wonder how much of my graphics power it is utilizing. Any idea? Do you think it would be worth while to appeal to the developers to have the program stereo enabled so LCD shutter glasses would work? I'm guessing the answer is no since most people have no use for them. I am eager to hear everyone's thoughts on this. Thanks to everyone who has responded to me as well.

---------- Post added at 05:02 AM ---------- Previous post was at 04:58 AM ----------

One more thing that has crossed my mind many times. Is there going to be a release for Linux, Unix, or MAC OS X?

 

[Face]

Is there going to be a release for Linux, Unix, or MAC OS X?

Of course I can't speak for Martin, but given the heavy use of Windows APIs the probability for this to happen is so close to zero that I'm comfortable enough to say "No".

 

[jedidia]

As for writing add-ons, if you already know c++, you can pretty much jump right in.
the sdk comes with the download by default, the documentation is mostly excellent except for a few calls that are not up to date. The shuttle-pb sample in the sdk is a great start to just fiddle around and experiment, and there's tons of tutorials that will help you with some of the more specific stuff. But all in all, if you're comfortable with c++, you'll feel right at home.

 

[kamaz]

Doesn't Orbiter run under Wine?

 

[doctor_of_physics]

Astrosmurf I remember that episode where Dreamy Smurf wanted to go to space.
Thanks for your advice as well. I haven't had an opportunity to have a look at the SDK yet but from what I was told it is a closed source program which means the source code isn't available. Without the source code I wouldn't be able to even start porting and from the looks of orbiter it would be a team sized job.(just guessing) We can make REALLY great addons and modifications with the SDK. Would it open with Visual Studio 2010 Ultimate or later? Thanks for responding to me.

 

[DaveS]

Astrosmurf I remember that episode where Dreamy Smurf wanted to go to space.
Thanks for your advice as well. I haven't had an opportunity to have a look at the SDK yet but from what I was told it is a closed source program which means the source code isn't available. Without the source code I wouldn't be able to even start porting and from the looks of orbiter it would be a team sized job.(just guessing) We can make REALLY great addons and modifications with the SDK. Would it open with Visual Studio 2010 Ultimate or later? Thanks for responding to me.

I believe the earliest VS or rather VC++ version required is 2005. So VS/C++ 2010 or later will work just fine.

 

[jedidia]

Astrosmurf I remember that episode where Dreamy Smurf wanted to go to space.

I only ever read the books, really :lol:

from what I was told it is a closed source program which means the source code isn't available. Without the source code I wouldn't be able to even start porting and from the looks of orbiter it would be a team sized job.

No, porting is impossible. But you mentioned plans to start add-on development, for which the API doesn't leave much to be desired.

Would it open with Visual Studio 2010 Ultimate or later?

Shouldn't be a problem. I'm using VS2013 myself.

 

[doctor_of_physics]

I believe the earliest VS or rather VC++ version required is 2005. So VS/C++ 2010 or later will work just fine.

I only ever read the books, really :lol:




No, porting is impossible. But you mentioned plans to start add-on development, for which the API doesn't leave much to be desired.



Shouldn't be a problem. I'm using VS2013 myself.

Thank you all for taking the time to respond to my messages. I am looking into creating some addons eventually so the SDK should really come in handy...(Handy Smurf there's another one) I haven't had a look at the SDK or the Application Programming Interface yet, but I have plans on researching them and the SDK documentation.

I too have Visual Studio 2013 Ultimate now through my MSDN subscription, I've just chosen to stay with 2010 ultimate for the moment.