From: Sander v. D. <sgv...@gm...> - 2011-10-18 09:50:43
|
Hi Patrick, First of all, great to hear you are spending your project on this, welcome to the community! Secondly, before you continue, have a look at RoboViz[1], which is an alternative monitor for RCSSServer3D, which was recently developed by Justin Stoecker of team RoboCanes and is now the de facto standard monitor used in competitions. It offers a debugging interface for agents, to be able to draw a range of geometric forms and text into the field. If you want to focus on visualization for 3D simulation, I would suggest getting in contact with Justin and see if you can work on that. However, RoboViz is geared towards the RoboCup, if you want to work on Simspark as a generic simulator, your plans as outlined below are all good, just realize that for the specific RoboCup implementation there is already something out there. What I think would be most useful for us as a league, besides extending RoboViz (and the server+protocol in order to make it all possible) with some of the extra monitoring and control features you mentioned, is a nice way to easily design new robots. This because we are thinking about and looking into working with different, heterogeneous models, or models where parameters can vary randomly, but we lack ways to easily do this. I have not looked at RsgEditor or ZigoratAssistant in a while, but if I recall correctly, they're broken with latest versions of SimSpark, or not fully intuitive (again, saying this not based on much experience with them ;) ). Another nice thing would be to have a GUI for configuring and controlling the simulator, for setting startup parameters and change them at run time. Good luck, looking forward to the end result! Sander On Tue, Oct 18, 2011 at 6:15 AM, Patrick Geib <Pat...@on...>wrote: > Hello, **** > > my name is Patrick, I'm a 24 year old Masters student from the University > of Koblenz (Germany), currently studying at the Osaka University for 6 > months. Here I am going to work on the Simspark environment within the > context of a "research" practicum under the watchful eyes of Joschka > Boedecker. (Actually it wont be "researching", but I will be focusing on > solely one project)**** > > My major subject is Computational Visualistics, so my plans for developing > on Simspark are mostly improving usability and/or graphical presentation. > From the Todo- and wishlist in the Wiki I could target (or at least support) > some of:**** > - New interface for different rendering engines, add OGRE support**** > **** - Enable new agent-server protocol to support using image sensor and > other things via new rendering engine.**** > **** - GUI for our simulator (possibly based on RsgEdit + > ZigoratAssistant, incl. easy construction of new robots and simulations, > moving robots on the field, etc.)**** > **** - Support Referee enhancements and trainer enhancements: (Drop a > player anywhere on the field. Drop the ball at any place (as drop ball, free > kick left or right) as is possible in 2D. Play Mode Control etc.. Control > e.g. via Monitor)**** > **** - Nice 3D visualization, including a stadium, animated crowd, > automatic commentator, slow-motion replay, etc.**** > **** - Training Capabilities through agent-monitor communication**** > > As i have about five and a half months of time I could probably connect > some of these tasks, but of course i will have to focus. For example > building a User Interface for Server, Monitor and Client Support (maybe like > WeBots) along with the possibilty to connect new modules for a RsgEditor and > new functionality would be possible. > At the same time, Peter Tissen (a friend of mine who is working here too) > is implementing Bullet as a pluggable Physics Engine optionally choosable > for the Simspark Simulation.**** > > First of all, to me it is most important to get feedback by those, who are > already experienced with Simspark. What is needed? What would be nice to > have/doable in this amount of time? What is definitely NOT needed? Whatever > will be done has to be accepted and integrated by the community, so it can > be of use and of course can be maintained and extended in the future by > everyone. So to begin with, in the following I have a list of ideas and > questions you may comment with whatever comes to your mind. The more > detailed, the better.** > > *What should a central user interface contain* > - starting server, monitor and agents**** > - controlling the server (game control, message overview, physics engine, > log control) **** > - controlling the monitor (views, rendering engine, video captures, game > camera)**** > - controlling the agents (message overview, message sending?, debug > interface?)**** > - creating and testing agents? (loading from collada?, annotating with > receptors and effectors?, coding?, visualize behaviour? control interface?) > **** > - be extendable to incorporate rsgeditor, further monitors, agent > visualizations...**** > * > Questions*: Is running most agents as simspark plugin possible? Or is it > better to offer some kind of debug messaging interface? How are agents > debugged in practice and could a central user interface working together > with server and visualization (see next point) be of help?**** > > My preference for an easy-to-create and -extend up-to-date GUI is > definitely QT.**** > > *What should an improved graphics engine/monitor be able to do?* > **** - Visualizing server or agent internal states? (view of agents, rule > checking, effector usage, agent state visualization)**** > **** - Improve Debugging/Logging by server and/or agents with a > documentation interface (visualizing and recording on request)**** > **** - graphics engine choosable? (currently built-in as fallback, > Ogre/Irrlicht as improvement). e.g. bind ogre to core scene graph via bridge > pattern.**** > **** - Shading, 1st alternative: GLSL Shading environment attached to > ogre**** > **** - pro: multiple render targets -> realistic lighting, improved > materials, point of view rendering for every agent, realistic sight > detection**** > -> implementation of Screen Space Lighting **** > -> implementation of Screen Space Ambient occlusion**** > - pro: Further rendering engines besides ogre can be connected the > same way**** > - con: bound to Ogre. When the interface should fail somehow, there > wouldnt be any improved shading anymore.**** > - Shading, 2nd alternative: basic GLSL Shading environment attached to the > monitors core, improving current indepandant shading ( allowing MRT Shading > too)**** > - pro: lightweight, same shading options like 1st option**** > - pro: easy and fast to implement, so i will have time for other > things **** > - pro: not dependant to ogre -> one needs no knowledge about ogre**** > - con: developing new shaders will be harder, as no combination is > possible natively**** > - con: lacking ogres support for Object loading, environmental > animation, scenegraph, materials etc.**** > - Object Shadows**** > - simple object shadows (blob under objects)-> easy, with ogre for > free**** > - directional shadow for each object -> easy because of flat ground, * > *** > - shadow mapping (allow shadows on objects)-> time consuming).**** > - Inner Shadows (Screen Space Ambient Occlusion, SSAO): only possible with > shader integration**** > - additional objects to render: seats, crowd, goal net, corner flags > (further objects would be easier when using ogre)**** > - graphics improvement: textures, sky, weather**** > - environment simulation (wind on grass, changing sky...)**** > > The main problem is how to improve the current monitor or create an > alternative one, that is easy to use and (most important) easy to maintain. > Various new possibilities like visual debugging and recording of server > internal states (rcssserver3d) and the agents could be integrated into the > visualization (or maybe better the GUI). I guess since rewriting the monitor > from scratch could lead to discarding any new implementation with the stable > one after im done, it my be better to make Ogre a pluggable option to the > current monitor. New possibilities for the monitor would most likely create > the need of extending the Server/Monitor MessageProtocol. Both implementing > Ogre as pluggable rendering engine and simply improving the engine already > in use are viable options. However, while creating a simple (yet good > looking) improved rendering style for the Monitor is an easy task, > connecting Ogre to the scene graph is not. **** > > So the Question: Is it better to simply implement a better visualization, > leaving much more time for graphical gimmicks, the GUI or > debug/point-of-view visualization and so on, or is it preferable to create a > flexible graphics-interface for the monitor and implement Ogre as the first > one, even if there wont be much more time for the actual visualization and > possibly more important tasks (central gui).**** > > This said for the two possible development fields... Again, the most > important thing is the acceptance in the community. I definitely dont want > to create an interface or program that cannot be used or maintained in the > future, should I not be able to continue. **** > ****Please send me E-Mails with comments, ideas, suggestions and anything > helpful you might come up with.**** > > Thanks a lot ;)**** > > Patrick Geib**** > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > > -- Adaptive Systems Research Group Department of Computer Science University of Hertfordshire United Kingdom |