Simpit Outside Visualization

My suggestion is either program an open source version of Sol7 or pony up $430 for the simpit version of Sol7. I advocate software solutions to correction over hardware. ;)

3194140896244ac54f52oin3.jpg
 
Um...wow? Thanks for the link, but those are basically an order of magnitude out of the price range I was planning ;)

My suggestion is either program an open source version of Sol7 or pony up $430 for the simpit version of Sol7. I advocate software solutions to correction over hardware. ;)
Nice setup.

Yeah, but can't you only use Sol7 on one computer? The design I was wanting to go with would pretty much require using multiple computers to do the rendering due to the high differences in the angles between the views...
 
Um...wow? Thanks for the link, but those are basically an order of magnitude out of the price range I was planning ;)

Checked the price after posting, and was surprised.
I bet one can make a low-tech homemade version of that. Maybe a solution to explore.
 
Nice setup.

Yeah, but can't you only use Sol7 on one computer? The design I was wanting to go with would pretty much require using multiple computers to do the rendering due to the high differences in the angles between the views...

Yep, that's the downside with Sol7. It's only for 1 computer. I'm still glad it's usable in any form though, considering there was no non-commercial access to Sol7 last year and the hobby version added more features and it 1/10th the cost of the commercial version. :)
 
Here's my gaming rig setup as of tonight. I also have a 720p projector over the screens. I can do 7680x1200 in games. The pic is Eve Online.
And he obviously has a cheap source of Samsung monitors, too :rolleyes:
 
Just wondering if anyone has considered using OMP and running 2-3 computers out of the same ship in the same simulation.. you can get really any effect you want. 1 computer to display 2-3 monitors. you could esessionally wrap yourself in monitors if you wanted.
 
I was wondering about that too talavar. For my first simpit I basically want to have a projector with just the forward view and a second monitor dedicated to the control panel with a mask overlay fit to the XR's panel. I'm on a tight budget (the projector will be home-made from spare parts and an old-fashioned overhead projector) so things like triple head-to-go are strictly verboten. I was considering using vertical spanning to arrange orbiter's window to divide the panel from most of the forward view between the two outputs on my video card, but obviously an OMP solution would be cleaner and provide a better view.
 
Just wondering if anyone has considered using OMP and running 2-3 computers out of the same ship in the same simulation.. you can get really any effect you want. 1 computer to display 2-3 monitors. you could esessionally wrap yourself in monitors if you wanted.

Neither OMP nor OrbConnect have that capability yet. If you want to add it, though, go ahead!
 
Neither OMP nor OrbConnect have that capability yet. If you want to add it, though, go ahead!

It still is doable with some restrictions.
All ship systems would only be accurate on the original display. An OMP connection could be used to display the big screen with a HUD.
 
OMP is alpha. It is not considered stable and time acceleration is not available.
Unless you are planning on helping with the developement of OMP I would not recommend fiddeling with it. Bringing up an orbConnect solution would be more feasable and stable.
After all, that is what orbConnect is for and using OMP would have to be considered a dirty hack. It just has a completely different mission statement.
 
OMP is alpha. It is not considered stable and time acceleration is not available.
Unless you are planning on helping with the developement of OMP I would not recommend fiddeling with it. Bringing up an orbConnect solution would be more feasable and stable.
After all, that is what orbConnect is for and using OMP would have to be considered a dirty hack. It just has a completely different mission statement.

I believe some ideas for this got kicked around at some point, but we never got around to starting anything. Basically, the route that I was thinking of going would be to have the ability for Orbiter instances to "slave" themselves to a "master" which is using UDP broadcasts of the pertinant vessel position data.

Latency wouldn't be as big of an issue as for OMP since it's only intended to be used over a local network. You'd still have to deal with issues of time synchronization, though.
 
OMP is alpha. It is not considered stable and time acceleration is not available.
Unless you are planning on helping with the developement of OMP I would not recommend fiddeling with it. Bringing up an orbConnect solution would be more feasable and stable.
After all, that is what orbConnect is for and using OMP would have to be considered a dirty hack. It just has a completely different mission statement.
One item missing is an Orb:Connect client plugin that would subscribe to and receive messages from a Master Orbiter and push the simulation state into its own copy. This would allow passive copies/slaves. The communication protocol is not the most efficient, so the $64K question is: Can you pass enough information through the API to keep the slave(s) sync'd?

Something like the communication part of RemoteMFD in something that fed the API rather than displays might work to test the concept.
 
I'd be willing to be a test subject for syncing multiple comps and displays. I've got a bunch of gaming hardware sitting around. Currently, it's a rack of systems with 12 nVidia GPUs total being used for my folding@home farm, but it can just as soon be testing multiple computer Orbiter stuff too on the side. Got a whole pallete of 21" CRTs I can experiment with too. ;)
 
Someone mentioned that Orbiter Direct X should be capable of outputting to the full Matrox TH2G resolution (3840 x 1024 if I remember right). Is this something that could be 'easily' fixed? Or does anyone even know why Orbiter crashes at resolution of over ~2000px wide?
 
Someone mentioned that Orbiter Direct X should be capable of outputting to the full Matrox TH2G resolution (3840 x 1024 if I remember right). Is this something that could be 'easily' fixed? Or does anyone even know why Orbiter crashes at resolution of over ~2000px wide?

The DX9 engine might be able to, but I'm pretty sure the current DX7 one can't.
 
The current built in engine can't do it. I can't remember the reason (it is somewhere in this forum though) but any OVP client won't have that limitation. I am not sure about the DX7 client of the current in-dev version, but as Martin simply detached it from the core I doubt it broke that limitation.
 
Back
Top