From: Erez S. <er...@pr...> - 2002-06-01 15:49:43
|
As a follow-up to Thorsten's message - I think it's best to do the sensor input using portals. Each sensor will receive the info from the portal as a 3d space (limited in the view range) and will respond to the data using what's written in it's module. This will provide the most realistic results, and allow us to add new types of sensors easily. But if we wish the engine to run faster, we can have some built-in sensor types (eg: IR, UV, Encoders..) that will return to the modules only the value they require (whether it's distance, or boolean values) and the required processing will be done inside the engine. It will run faster and shouldn't lower the quality of the result if we do it right. In any case, the users can always choose to build their own module that will recieve the full data (the 3d space).. As for programming the virtual robots - I think that for a real simulation, we should not only simulate the physics of the robot, but also simulate the proccesor. What I mean is that the commands to the robot will be given using a machine-code set (depends on which processor). Machine code is: 1) More realistic 2) Faster than scripting of any kind 3) Safer than changing the source-code (especially for ppl who aren't in this project). We can also support several processors with different machine-code set for each. Example: This year I build a robot with a HC12 processor . I still have it's full source-code (in asm). If, when this project is done (or partially at least), I can create a copy of that robot into our engine, and put in the HC12 code of it (whether in asm or compiled), and it will run like it ran reality, then i will be able to say proudly - "We did an exellent work!!" -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup |