Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: iadesdragon on April 30, 2010, 09:45:09 am
-
Wouldn´t it be cool to make FSO see your head? I Know we have TrackIR support. But Face API simply tracks your Face... using the ( build in ) Webcam you allready have.
As far as i understood their offering, FaceAPI is free for non-comercial use....
Any of you hard core programmers willing to give it a try?
http://www.seeingmachines.com/product/faceapi/ (http://www.seeingmachines.com/product/faceapi/) :nod:
-
trackir framerate = 120
webcam framerate = 30
youre better off with a wiimote+freetrack than cheap webcam.
or since trackir 5 came out 4s are pretty cheap and still offer 6dof.
-
I'd still like to be able to use webcam instead of TrackIR.
If somebody wants to use TrackIR, OK, but I'd like to be able to have face tracking without spending a cent.
-
His point is performance would probably be sub-optimal with a crappy webcam, even if it 'works' with it. You'd at least want to get a halfway decent webcam. Plus, FreeTrack supports webcams too and should already work I think. But you still want a quality cam, preferably 60fps at least.
-
i dont think they even make 60 fps webcams. the point of a webcam is to produce a small image that can be easily moved even over low bandwidth connections, so the performance is intentionally kept very low. im sure they exist, but your probibly gonna pay for it (to the extend that your better off just getting special purpose hardware). the dot based algorithms are a lot faster than the face tracking ones, and it doesnt require much processing since most of the work is done with a light filter. faster means less lag in the input.
freetrack support for webcams isnt bad though and sometimes 30fps is enough, though i find the low response time can be somewhat nauseating. i find cheaper webcams without a whole lot of extra processing work best (the trackir site keeps a list of whats good and whats not), and for an ir filter floppy disks work well, get about 3 ir leds and rough em up with sandpaper. figure out what their forward voltage is (usually between 1 and 3) and find a power source (old 3.7v cellphone batteries work nice) hook the leds in paralell and use a voltage divider if needed to keep from giving the leds too much juice. then you need to build some kinda frame to support them. if you use a wiimote try to space them out as far as possible. though the wiimote kinda has a lower than necessary field of view so it needs to be further away, but its ir camera is very sensitive and can work across a room if need be. getting the wiimote to talk to bluetooth is the hard part, but almost any bluetooth stack other than the one that comes with window works.
-
What i found tempting with this approach....
it (seems to ) be free, and you do not need ANY targets at all. SO this would work werever you go... ( as long as there is a webcam )
-
but you have to not only put up with a low refresh rate but also an extended lag time to process the data. face tracking algorithms require checking multiple consecutive frames to get an approximation of what a face is and determine how to track it. it needs to find a number of distinctive points, usually eye glare, tip of the nose, chin, dimples ect. point is it doesnt know what its looking for so it needs to check more frames and find spots that change the least. then it can establish a model and track it. or course if the lighting changes or somone else uses it the system has to re-adjust and come up with new points to adjust by. allowing the camera to auto-adjust lighting levels, exposure, white balence, ect almost always cuts your framerate and requires processing time.
with targets and filters you only need to do some basic pixel math to isolate and threshold points and since the pattern is predefined and uniform you only need one frame of data to get all the info to compute a transform matrix. usually you set your exposre to as short as possible but long enough to get the points. but when it comes down to it the physical infrared filter does 90% of the work and you get your angles faster.
now you really want a face tracking api you probibly dont have to even integrate the api into the engine. i know i seen at least one face tracking proggie that output to some kind of mouse control or ppjoy interface.
-
I wonder if we should institute a rule that anyone requesting a SCP feature has to have more than a certain number of posts.
-
i wouldnt say that the idea is totally bogus, i just think there are better alternatives.
-
Oh I definitely agree with that. But more importantly, I'm just wary that this is a request from a new user, who may not stick around on HLP. If we go and spend the effort needed to code this FaceAPI feature, is he going to be around later to use it?
-
Hey Guys,
this has been more like Thinking Aloude, not a feature request at all. I only wondered if this might be a kewl thing because there is no soldering ant thinkering with your web cam involved...
I have freetrack runing all right and just got myself a trackir... but i also saw ( while seting up the stuff ) that a lot of people have problems getting the LED stuff work or do not like to spend a lot of money for this...
Besides you are right in some respect, especally when it comes to frame rate. The pure math power should not be a big deal with a up to date machine.
Anyhow, im more of the embedded systems guy, so ask me if you like to interface a 6DOF Moving platform or real usable hardware MFD`s.
And, while this account is new, im with Freespace and altough FSO for years now, only i`v been off from active use due to dipper duty for quite a while and simply did not recall wich original account i used :-)
BTW. unbeliveable grate work! A lot has been fixed, enhanced, since i last used FSO...
Rgds...
-
Anyhow, im more of the embedded systems guy, so ask me if you like to interface a 6DOF Moving platform or real usable hardware MFD`s.
funny you mention that. ive been playing with arduino for like the last 3 months. ive also written a lot of serial code lately, for a variety of reasons. did an interface program for ppjoy so i could send serial packets containing joystick info, which i captured from a number of various devices. also managed to control servos from a serial terminal. i was actually thinking of doing a generic scriptable serial interface of sorts so that freespace would have some facility for operating external hardware, mfds, and so on. alternatively some kind of shared memory interface that would allow fs to talk to some other program on the system (which in turn could talk to hardware). win32 serial interface seems to essentially involve a file handle so it might be possible to open a com port through the existing cfile interface. my duemilanove seems to be capable of about 230400 baud, which is enough for operating mechanical devices like servos, or transmitting some small amount of data to an mfd.
-
Nuke,
i`m with you! Must be mind melt :-). That is exactly what I was thinking about. Having a interface to Freespace like today is quit common with FSX or X-Plane. I just started doing hardware for an MDF some days ago (not especially for FSO however) but would really be happy to have someone on the PC / MAC side assisting in doing the Host side coding.
Because i believe having a usable hardware cockpit with MDFs ans switches and such, probably even combined with a "simulator chair" that at least ads pitch / roll and yaw to the experience would REALLY add to the overall experience of the game.
However, i need to find a way to have FSO send the critical data to USB or ( maybe easier and better ) an local IP A dress ( which again is a embedded system )
Envision something the size of a a deckchair with a 32" Monitor mounted in front of the Gamer underneath this monitor you got 2-3 4-5" LCD MDF with touch and a bunch of buttons all around.Add some meters and switches as liked. Then Equip this with a TrackIR and something like the Logitech G940....
now simply screw down your Computer on the back of this chair (serving as a counter wight as well...
Since all Coponents are mounted to this very chair only thing that needs to be supplied to it is mains. THis allows for the chair for infinite rotation in Z while it chan lean in X and Y by aprox 45°....
I Myself have like 20 years of experience in Embedded Controll of fast production machines beeing the principal engineer on several projects that involved a lot of fast and precise movement.
In my privat lab i am able to do Layout and have PCB done, i can design even complex 32 bit embedded systems with graphics, Ethernet and such...
Additionally there would be the possibility to do organize and manage hardware build runs for people interested in building one ( because i know that most people do not like to solder SMD stuff nor have experience doing it)
So all we need is a Team and enough people being interested in doing the work, moding the ships etc...
But, this would be a Huge Project lasting several month if not years... ( while some of the stuff could be used from other projects, besides the really cool stuff most often is not open source )
So if there are enough People interested (we need quit some units to build to keep it cheap) and there are some willing supporters...
(ANd people that may live with my somewhat imperfect English due to me being native German :nod: :-) )
Rgds,
-
thats about the kinda thing i was thinking. for communication i was initially thinking of doing a serial interface, of couse in a game engine it might be advisable to run serial code in another thread. mt is something ive never done before (unless you consider stuff i did with my lego rcx :D ), but i here freespace uses it for specific things such as input and i may be able to use that as template. ip or usb is definitely a possibility, especially ethernet (theres an arduino shield for that). i like arduino because its cheap, expandable, and very easy to get into even without any ee experience. but the idea is to make the game side interface scriptable with lua so that it is as versatile as possible. the game really only needs to read and send packets to a micro controller and so long as the uc can decode the packets and use them then pretty much anything goes.
a full scale simulator is kind of out of my budget, though i was thinking of a scale model "smurf simulator" made from r/c components as a proof of concept. so far i have my arduino duemilanove and 2 arduino-in-breadboard setups, all running atmega328ps and was thinking of setting up an i2c network. the arduino board would kinda be used as the master device and would talk to the computer while the other two would essentially be slaved to it and essentially control servos, motors, and read sensors. assembally of the smurf sim is a non-issue, so right now its mostly a programming job.
also forgive my bad english (im american) :D
-
Ya, did some thinking today...
Basically i believe using one of the new 32bit PIC micros would be fun... they have a reasonable horspower of aprox 120 MIPS and feture a lot of nice interfaces including 10/100 MBit ethernet.
I altough thought it would be nice and hady to have this in one board.
So all you need is a power supply ( i would recomend a of the shelf one because we ar hobists, besides i even could design one) and a ethernet cable you plug into your PC or Switch.
The PIC is abprox 10$, and would give half a MegByte of Flash along wit a good quater of a meg RAM. What i am thinking about now is how one would layout a cokpit for a space age fighter. Shure no old style handed instruments, those wouldn´t work in space. One big LCD? to costly....
what i think might be fun is 3 seperate touch screen LCDs that can be configured as liked... these can show all that is shown arround the main hud ( comm menu, weapon selection, tagret screen etc.. ) and you can e.g. change the pwer system settings by sliding your finger...
Only downside i can think of right now... not eough computional power to do other than wire frame models for the target display. and the models have to be imported to the panel first..
i really thing one 4.3" LCD in center acompanied by two smaler (3.5"? or 2.4") LCDs left and right would be a good starting point...
These would be aprox 120$ total if you buy them single unit wise at newhaven displays. add the board an switches gluelogic and some 2D grapichs controllers...
Bet 250$ something for the full Cockpit-Kit ( plus you have to build something to go allong as a housing yourself.
About the "rocking chair", figure 500$ should do for the system parts 100$ each for x and y drives another 100$ for yaw drive ( optional ) 100 bugs for the Electronics....
so if you put the PC aside a total kit including something like the logitech G940 would cost within 1500 to 2000$ i would guess from first planing, and depending the amount of kits you build ( if there are enough people intrested would be a great thing)
Biggest development herein is, as always, software...
About i2c, generally easy to use but only few OTS parts you can use for something like that ( two if i recall right a D/A A/D GPIO combi unit and a 8Bit Parralel IO ) both of them quit costly...
But, as i said, i think this only can be done in a team efford and if it is the EE side, count me in on that...
I`ll do some sketches tomorrow to give a better vision on what i thing about...
Lets do a first Layout, User Interface is what we ar talking about... once thats done... we can talk hardware :-)
So however is intressted input please!
WHAT WOULD A SPACE AGE FIGHTER COCKPIT LOOK LIKE?
-
Maybe we need a new subject ;-)
:lol:
-
yea that too, maybe some moderator will come and split the topic :D
mini-lcds are rather overpriced and if you dont mind having an analog interface you can get 3.5" 720*480 lcds directly from china for around 30 bucks. i so happen to have one right in front of me, its a little bit too small for an mfd though. larger screens can be really cheap if you look for broken portable dvd players (90% of the time its the dvd player thats shot and the screen is ok), again analog interface (probibly also @ 720*480).
either way most modern video cards have at least 1 analog display port that takes some kind of splitter cable, so you might be able to run graphics right off of the video card from a program on the computer. if you know how to do some signal processing you could do some kind of frame multiplexing to transmit 3 or 4 different video sources over the same analog line and display them on separate screens.
the mcus may not be able to do much in terms of rendering, but i bet you could use dxt1 compression (4 bits per pixel 5'6'5 but requires dimensions in multiples of 4), to allow digital transmission of images. at 720*480 its about 172k per frame. serial wouldn't cut it but ethernet or usb could do it just fine. the mcu would have to decompress the data and forward it to an lcd driver or signal generator of sorts.
-
Well, I have found 30 frames per second to be sufficiently accurate for FreeTrack purposes in IL-2 Sturmovik - with a carefully set up profile to adjust turn rates, damping and smoothing. The response time is fast enough that there's no perceivable delay, and you can keep the view static enough that aiming and performing other accurate maneuvers is very much possible.
Granted, the program (FreeTrack) interpolates it into 120 FPS with a multiplier.
However, for a computer it's much easier to initialize a plane using three dots as reference points than a flexible, shape-changing object like human face, and that's definitely going to increase the amount of cycles that it takes to decide the perceived position of the head at any given time.
-
Big advantage of the somewhat more expensive mini-lcds is, you can buy them on a regular basis, you get full support by the Distributor etc.
Problem is that most LCDs have some specialties with them so you can not easily exchange them in a design, therefor using analog interfacing on the other hand might seem a advantage, however i usually found those ( dvd player ) PAL or NTSC Analog Displays ( especially the China style ) to give a unsatisfactory crappy image.
I think, with all the afford required to develop & build something like this, the outcome should be pleasing and especially in a way that it ( we are talking open source i believe ) van be re-build easily by others. Using ebay parts proved doom to quit a bunch of projects in the Open Hardware domain already.
But, as it seems, there is not to much interest in such a cockpit or nobody found our topic by now ;-).
Good thing however is that we do not have to reproduce a "real" cockpit as the Sim Builders do therefor there are quit some options.
Another possible approach would be to use a reasonably sized OTS LCD Panel with DVI ( lets say 15-17" and only design a Sliders and Touch Panel overlay that one monts directly in front of it.
This unit only as cutouts where we like to have MDFs so only the used areas of the LCD are visible. PC/MAC does all the stuf rendering on the secondary display ( The LED Pannel )
The Switch and Touch Elektronik board only does emulate kind of a keyboard connected via usb...
Is there a way to tel FSO to render the secondary HUD elements to a seperate View?
THis would speed development and also cut down cost.
Quick look to the bay shows 15" 1028 x 768 DVI is a cheap buy.
-
ive had luck implementing joystick axes, sliders, and buttons through the ppjoy joystick interface. i read all axes and buttons on the arduino, format the data into a serial frame. im using a simple frame with 170 as the sync byte, followed by an x number of bytes for buttons (1 bit allocated to each), followed by packed 10 bit joystick data (0 padded at the end) and a 1 byte checksum.
ppjoy just so happens to have a code sample for creating programs to talk to the virtual joystick driver. im already working on a (still rather buggy) command line program for reading a serial packet and reporting the axis and button states to ppjoy. that should cover input from the mfds, however you would probably need to mix in axes and buttons from the joystick from there (unless you cockpit had its own built in, which could send its axis data over the same interface), and ppjoy is kind of limited to i think 16 buttons and 8 axes and doesnt seem to support hats (not sure). another alternative is using glovepie, which could convert some of that data to other formats (keyboard, mouse, ect). needless to say freespace only uses 1 joystick.
if analog lcds dont cut it, there are a number of digital screens on sparkfun (http://www.sparkfun.com/commerce/categories.php?c=76) to choose from. since i have no experience using screens with micro controllers i was thinking something like this (http://www.sparkfun.com/commerce/product_info.php?products_id=9363) to get me started. however after glancing over the driver code im concerned that there wouldnt be much space on the mcu for much of anything else.
as for rendering, the freespace renderer only supports 1 display, and i doubt thats subject to change. however freespace does kind of support render to texture, if these dynamic textures could be sent to an external device, then it would be possible to have game rendered graphics on the mfd (of course im not sure what pixel format they would be in). it however wouldnt be anything as big as 1024x768.
-
Ahhh, to bad, simply having the Game Engine Rendering the Instruments / MFDs to a extra pane would have eased things alot ( thats what flight sims often offer to have the cokpit fiew rendered to another monitor.
OK then i believe we have an idea what to do i would think about an single MDF unit that can be 3.5" to aprox 5" (same Hardware different LCD module ).
This unit comunicates via USB or Ethernet ( Ethernet beeing prefered ). Display area will be touch senitiv ( why should a interface in 2335 be wors then todays smartphones ;-) ) surounded by a bunch of buttons that can be lit in several color and gave the option to insert text masks ( named buttons )
So if you like you can use several of those to build whatever cockpit you like.
This is ( besides the ethernet IF, what makes me quit happy because this setup will work for other sims as well making this an even more worthwhile project ) something i have on my drawing board anyway...
I think i can build a 3.5" version for aprox 3 time the price of the Nokia Add On board.
let me think....
SO i teak it you are quit eperineced in C / C++ are you?
With the Microchip MUC we get the worst for free (TCP/IP, Graphics, SD_Card Support, FAT16/32 etc... ) and the Dev tools are ( almost ) free ( besides buing a pickit2 debugger for 50$
-
You guys should look into how the Battletech Firestorm pods are set up, the ones Virtual World takes around to conventions and such. They're more than happy to talk about it with interested parties.
-
ive heard of those but ive never seen one. id just love to sit in a mech simulator for awhile. :D
SO i teak it you are quit eperineced in C / C++ are you?
i wouldn't say im an experienced programmer, im just apparently very good at learning technology. i have no formal education in programming and electronics, aside from some highschool classes. i do have a 2 year degree in network admin (and zero experience in the field). that said programming on the pc is a lot of headaches for me. huge bloated libraries that theirs no hope of learning the internals of, and of course inconsistancies between compilers. at least with microcontrollers the code is kept simple so theres not a whole lot of hidden magic that makes your code work.
-
Nuke,
thats a good starting point right away. While I'm more like a long time pro with this stuff, I'm not to good with PC stuff, nor do i believe i`ve got the slightest chance getting into SCP Code Base.
While i believe I should be able to design the Hardware as well as the Embedded Software and a White-paper about how the system works, i really think we need a Pro in SCP Code to discuss the hows and whens of the SCP integration. We need to figure out how we get the HUD info out of FSO, as well as the 3 Dimensional Dynamic status of the Player ship. (6 DOF values ). Additionally there might be the need to have FSO listen to "key presses" reported over TCP/IP.
ANYONE willing to do some advanced thinking on the topic?
MODERATORS: Any chance we change the topic of the thread? I believe we really lost the original point now :-)
-
Swifty is rewriting the HUD code, asking for some kind of hook system now would probably be a good idea. He may even already have something like that in mind. Of course you'd want input as much as output support which is likely beyond what he's working on currently.
-
we really just need a way for the game to talk to other things from the scripting system. scripting has access to physics data, position data, some facilities for rendering, ect. should be able to code up some kind of serial interface with only a few lines of code and provide an interface to it from scripting, of course if you want to talk to usb or the network, youre probibly gonna need more code. the interface would probibly consist of read/write buffers, a send command, a read command, probibly a command to check if any bytes were received, a setup command, and possibly some conversion functions to accomidate lua's weak typing (lua would convert any data to a string and send it as chars, these could be read at the other end as binary).
Swifty is rewriting the HUD code, asking for some kind of hook system now would probably be a good idea. He may even already have something like that in mind. Of course you'd want input as much as output support which is likely beyond what he's working on currently.
pretty cool. if theres support for spewing out individual gauges as textures, then we would only need a lua function to read that image's data, get its format information, convert as neccisary and send it out (over whatever communication interface we use) to an mfd device. il need to see what swifty is up to because i wanted a few hud related features (lua hook as gauge for example, but thats for something entirely different).
-
Using the script system sounds good, might be quit flexible and one could even implement MOD / Mission specific actions ( like special Target screens and such )
I will have some time off over the weekend, so i got some time to spend on doing a sketch and white paper on the stuff. I thing what is required is some kind of a mapper application that connects whatever the script tells to the actual hardware setuo that might vary from person to person (1-3 MFD extra switches e.g.)
If we can get swift to support this, i think we can manage to implement this. I think i even can get the help of a friend on the Mapper Application stuff.
In this case there should be all the people available to do this. ( if you like to Nuke and if we get some support by swift if needed )
I planed to do a MDF style system for OSX anyway ( because there is non available right now ) and tweaking this to have a specific mode that is perfect for FSO will be fun.
( I even found a way to implement real smoke if the MDF is destroyed ) ther can be several defekt animations on an MDF so flickering, dead, broken screen, Flash & Smoke :-)
As i although still like to make it move, is there a way to have a script executed permanently so that i can get the 6DOF vectors several times a second? I thing i figured out a software scheme that should give unbelievable cool motion feedback with reasonable simple hardware & electronics ( still heading to archive 500 Bugs material for the Moving seat )
-
i talked to swifty and i think he was already planning for hud gauges to be rendered to texture. if so then we would just need an communication interface to send the data over, and something to convert a texture from bmpman into a stream of characters. the comm interface should be kept as application agnostic as possible. its not really that hard to come up with a command protocol.
as for the vectors, scripting has access to ships velocity, orientation matrix, rotational speed and so on and can run every frame. if acceleration is needed you could just compare last frame's data with the current frame. it should be simple compared to some of my other scripts (http://www.hard-light.net/forums/index.php?topic=69358.0).
im currently looking for an api that can handle inter-process communication with an external application. im trying to find something that will work on all currently supported platforms, and probably something that has a comparable license.
-
Thats good news in fact. AT least my hardware is able to handle JPG decompression hardware wise.
I Spoke to newhaven today about displays and they can provide a wide variaty of Sizes. So actually my hardware will be roughly the size of a credit card. and you can hook up displays 2.4, 3.5, 4.3 or 5.7"
to ease design all of them initially will be 240x230 full color. in front of or surrounding every panel there will be a mezzanine board what allows for a selection of switch arrangements to complete the MFD.
I hope to finalize the schematic in the next few days and have layout done quickly so i can have some 2-3 PCBs done on my next PCB run.
the layout will support USB, Ethernet or Both additionally micro SD is supported so there is the option for vast storage up to several gig of Flash ( for small money ) the graphics sub system has a additional quarter meg of RAM for display buffers and is able to decode jpeg on its own ( additionally mjpeg seems possible ) the smallest version might go for 100$ while the 5,7 will be like 60$ extra so 160.
Landscape as well as portrait will be a simple means of software config. Anyway every kind of data will be excepted either raw data ( text strings, menu arrays, speed velocity percentage whatever ) and the hardware should even be able to render wire frame ship models. ( processors will be in the range on 10$ each )
i`ll start working now on the sketches to further detail what i plan to do and design.
-
btw. got my trackIR today... way kewl now i really need some ships with good internal cockpits. For some reason i did not figure by now your mod is not working with my 3.6.12 RC2... ( lots of errors & chrash )
Thanks for the link to your scripts, i followed your work for a while and thats one of the reasons i´m willing to do open source work here ( seriously this will be my first open source project after we failed badly 15 years ago (which in fact has manly been because 15 years ago we still had the dark ages Internet wise :lol:))
-
i kinda want to roll out a nukemod mainenance release to fix some of the bugs (last release is nearly 4 years old!). theres some stuff thats almost ready to be added, a couple htl models that are very near complete. haven't really added anything new mainly because i was working with the scripting system. il probibly release it after the 3.6.12 rc phase, since new bugs may manifest before the code is finalized. the scripts on the svn are still in development, but you might want to check out the cockpit demo. it has cockpits with animated interior and render to texture radar and camera panels (also has things like uav drones, laser guided missiles, multitargeting, and a bunch of input related features.). i tested it against 3.6.12rc2 before i uploaded it so it should be working.
-
Yah! Cockpit Demo sounds pretty cool, is there i zip? or do i simply fetch it from svn?
-
fetch it from svn. i havent provided a zip yet because its still in testing. once i make it more user friendly il throw a zip together. its not obvious how to use some features of the game. you can edit input.tbl to change settings (just be careful, my tbl parser doesnt spew out useful warnings yet) and controls for the mod. there should be some missions to play. if youre using a hotas you may want to consider using the split throttle feature, theres also a way to use the mouse to control latteral thursters if you so happen to be using a joystick with a trackpoint mouse on it.
im also looking at named pipes for getting data into and out of freespace. should be able to get at them with file i/o functions. however im not sure how multi-platform they are. but it might already be possible to use them from scripting with cfile. it would still require an external program to talk to hardware (but ive already written a few of those).
-
im currently looking for an api that can handle inter-process communication with an external application. im trying to find something that will work on all currently supported platforms, and probably something that has a comparable license.
Here's a really off-the-wall idea - how about using CITP to do this?
CITP is an open, royalty-free protocol for Media Servers and Lighting Control applications designed to stream multiple video plus a lot of 'background' data, and includes automatic discovery of 'sources', 'sinks' and controllers.
It's multicast and TCP/IP, so works on any IP network.
The protocol definition is available from http://www.citp-protocol.org/ (http://www.citp-protocol.org/) - I'm pretty sure I've got a reference implementation somewhere.
Admittedly, using it for game data is about as far away from the core idea of CITP, but it's a pretty robust protocol that's used pretty widely in the theatrical, TV and 'live event' industries, where 'real time' is extremely important!
-
the idea is to talk to another program on the same computer, and then that program could in turn talk to whatever interface(s) you require. since this interface program is running in an entirely different thread, it wont slow down the game with interrupts (serial for example is notorious for this). any api or protocal can be implemented into the middleware as needed. since simulators are a major diy project with a number of custom hardware and software components, it is good to leave the interface to the game as general as possible.
-
The network stack is a perfectly fine way to communicate with other applications - it's probably the most platform-agnostic method, and it lets you run that 'other stuff' on a completely different PC if necessary.
Pipes are quite different across the various operating systems.
- *nix tends to do pipes much better. They always feel like a bolt-on in Windows.
That said, there's a lot of better ways to send video streams, for example it would be cool to use the same protocol as used by Windows Media Player and MythTV etc for sending television across a home network. However, I do not know where licensing stands on that one, and there appears to be less capability for metadata (though I could be wrong)
-
sounds too specific though, and the last thing i want to do is throw a new api into the engine without looking at everything first. im sorta screwing around with named pipes right now to see what they can do. good ol quake style ip loopback is a good idea though, but id have to look into how it would work with the existing netcode.
-
The planned memory tracking application was going to be communicated with via TCP. This could function similarly. Would be good to make the system for that generic enough to be utilized by various interfaces.
-
Hi All,
promised to have some updates on the hardware stuff, however there has been some drama in the last days so i did not have a chance to sketch anything ( my father in law managed to lose our family dog in the woods and we had to SAR it :-) for three full days )
however... to get an idea of what i plan to design in means of motion...
have a quick look to www.bluetiger.com (http://www.bluetiger.com)
Tonight is sketching time anyway...
-
OK, a little update for now.
I Figured a way to design the motion platform so that it is able to perform the same range of movements that you can see in the Bluetiger Demos.
Basically i will build a 3DOF moving platform like the part underneath the seat platform. My design is different tough because i thing this should not be bigger then the usual office chair.
On top of this there will be a construction that is very similar to a deck chair with some prolonged arm rests to hold throttle, stick cockpit. Additionally it will support a mount for an reasonably sized LCD Screen.
All the g-force magic will be done in a micro-controller that controls the three motors used to move the platform. All that is required to do is to permanently send the orientation and velocity of the craft ( FSO Fighter, X-Plane Aircraft, M$ Flightsimulator etc.. ) to the Moving Base using UDP ( Thats easy did that on quit some of the machines i designed in the past, this one e.g. http://www.datacard.com/products/products.jhtml?contentId=96316UdabtieZ2 (http://www.datacard.com/products/products.jhtml?contentId=96316UdabtieZ2) ). UDP is fast and easy to use and you do not need to care about re-transmitted data blocks.
Target is to make this moving base as well as the cockpit controllers as easy to build and especially cheap as possible.
THe Bluetiger Solution e.g. STARTS at 6950$ ( thats only the moving base + the platform atop )
I believe they do not sell a lot of those...
I am, right now, at a BOM cost of approx. 1200$ for the base and still am working hard to get below 1000$. However this is the price for all the stuff required so a kit might be a little more costly.
You can build any style of Seat / Cockpit / whatsoever upon this base as long as total wight ( including pilot ) is below 200kg total. ( Maybe 250 need to have a friend calculate the mech. numbers in detail ).
The Cockpit panels now are similarly simple in design. A CPU board talking UDP that supports a range of LCD`s size of 2.4, 3.2, 4.3 and 5.7 inches all of them 320*240 Full color. ( the 5.7 might be used with a higher resolution as well. ) in front / surrounding the LCD a Switch / Button / Knob assembly is mounted allowing for several ( easy to change ) configs of your cockpit setup ( you know, i do not only play FSO for fun but although other SIMs since I used to have my on plane and once had a pilots licence ).
You can set up this cockpit in any way you like using one or more CPU boards. This will allow for very classical meter style cockpit for General Aviation as well as futuristic "All Glass" cockpit layouts like one would use for FSO. All the LCDs are equipped with touch screens by the way.
The CPU boards handle pre defined graphics as well as basic animation and text display, additionally there will be the ability to stream low res digital video ( format TBD maybe MJPEG because hardware might support this directly )
Main target here will be to keep hardware cost as low as possible.
Still the main goal of my little ( or not so little ) Project is to build something that really adds to the realism and involvement into the game but still be very affordable ( Today you can build something like this that really is close to ONE specific aircraft nut you will need month to build it and a reasonable amount of money )
This should be fun i believe not an obsession therefore i think a usable moving cockpit for "Gaming" ( not ultra-realistic sim ) should not exceed 2000$ in a basic configuration and it should not take more then some evenings to assemble it and get it up running.
i´ll design this anyway for use with X-Plane on my MAC ( there is almost nothing like this with mac support right now ) but would love to use it with FSO as well (PC and/or Mac).
SO if there is interest to have FSO supporting this, let me know and we can setup a sub-project ( might even host it on my server ) that opens the gate on FSO.
-
Orientation has no meaning in space. How is it going to handle that? Really all you can take into account is velocity and acceleration. Acceleration being the important one.
-
Ya whatever..
Relative orientation then it is, i can map anything that comes along as long as i can compute something that results in a relative positional change.
I think we all still believe that a space fighter pilot still has a somewhat wired feeling of "selvelocation" inside the weightless vast of space.
As well as there is some kind of vodo mechanism that saves him from being crushed by acceleration. ( our silly little world will give us a sensation that down is where our butt is so we need to simulate the fighters relocation to this because otherwise or mind will not make believe ) since i cannot turn, bank, yaw, roll whatever indefinably with the mechanism i need to trick the mind into believing this happens.
Basically what i can do is simulate changes in relative velocity so any vectorial change will result in a swipe to this direction followed by a (as slow as possible ) return to zero.
However, all this can be changed by setup ( and software change since all electronic units can be updated on the fly ).
So don´t worry once the machanical forces of that mechanism work out, the rest is code...
-
Relative to what? I mean in a flight sim, if you have a 30 degree bank but constant velocity, that affects things. The chair likely leans or something. But in FSO, there's no need to because there's no gravity. If the chair was suddenly arbitrarily tilted to one side, I'd wonder what the heck it was doing. The only time the chair should react is when there's an acceleration, to simulate the G forces.
-
i think he means monitoring the delta in the velocity vector. if there is a lot of change in the vector between one timeframe and another, (not really frame by frame because i doubt the mechanics could actuate fast enough), probably about every 250-500ms. the amount of change signifies how fast of an axis of the simulator shall actuate. now if theres not very much change in velocity then the platform very slowly tries to recenter itself for the next big manuver. for changes in magnitude you can simulate g forces by playing with the pitch axis of the simulator. for the purpose of a space sim i think orientation of the spacecraft is less important, unless you need the vector in a different frame of reference (such as relative to the ship). you cant simulate zero g, that is unless you dont want to drop the simulator out of the back of a c130 and fly while in freefall :D . for simulators its less about directly converting virtual movement to mechanical movement, but rather convert virtual movement to perceived movement. simply looking at a screen with a simulated world on it is enough to trick the mind into thinking that what they see is whats going on. the simulator plays on that by providing inertial stimuli.
-
If so, then we're saying the same things, but there's no need to say things like 'delta in velocity vector' or 'change in position' when there's already words for those things :P
-
Nuke, your right there needs to be quit some soothing inbetween ( the mecanics will be reasonably fast, it can move approx 8 cm in only 1 second. The trick will be to make it feel right all the time and i think you really need to do some trial & error to get it right.
Not a big deal however since i would like to have my code arranged in a way that everyone can setup his personal and preferred response.. ( and although movements )
-
reducing the seat to 2DOF would however reduce cost and afford a lot. What do you think? Does the seat need to move up and down ( this motion is technically demanding, force wise )
in 2DOF it would only tilt and pitch. ( or should it have yaw as 3rd dimension this would be a lot easier )