I'm leaning towards the fact that these frameworks were not meant to handle such features and demand on cpu performance. I'm thinking the best way to do this is to break the guidelines and do the following:
1. Away3DView (which contains rendering on enter frame, camera etc and has logic requires the reference of multiple views (3D object views only). 2. Away3DMediator (which simply listens for notifications from the standard 2D application) Then from here we can add views and methods to the Away3DView which would carry out any functionality we require. Encapsulate all this in a sub folder within the view so if we do decide to break down camera, scene (re)generation functions into sub classes for extensibility then it will be confined to a single location. *Who's up for building the Hello Robotlegs Away3D cube collision example?* The gauntlet is thrown down... The challenge is on... Who's got this sussed? Who's the man? Who's going to be the first to have sorted this issue out once and for all? First prize gets a big thank you from many developers who face the same problem and probably a high read count from google searching on this topic ;) D On 22 March 2011 17:22, Alessandro Bianco <[email protected]> wrote: > That's an interesting point of discussion ... > > In the last game i developed (something like 2yrs ago and with one of > the competitors :p) I structured the whole application with PureMVC (i > had a bunch of other areas which were game-related) but when I had to > develop the game itself i found that the actors (view, rederers, > cameras, objects, etc) were too much "coupled" to let PureMVC's > structure get in the way. > Also, I feared that separating too much those objects would have had a > negative impact on performances (which weren't great at the time). > > So now after 2yrs, other developers are managing the rest of the app > quite easily, but when it comes to the 3d or the physics I've to step > in and handle the new requests, which is quite painful :) > > It would be great to find a wat to better "structure" also this part > of my applications .. so if anyone has some advice or use cases to > share i'm sure everyone would appreciate :) > > Bianco Alessandro > > > > 2011/3/22 Darcey Lloyd <[email protected]>: > > Hi, > > Anyone got any examples and source available of a simple Away3D setup > using > > RobotLegs? > > A Hello Robot Cube example if you like? :) > > Much like with the PureMVC I am not happy with how and where I have my > code > > to manage the camera, view.render, primitives and most of all > > the interactivity of 3D primitives especially if they are considered > > separate views/components. > > I've quizzed some guys in both RobotLegs and PureMVC google groups & > forums > > but they come back with answers I'm not 100% sure about and I don't think > > they are 100% sure with what is correct either, especially when it comes > to > > using 3D within these frameworks. > > > > An example: > > If I was to have the following views: > > Away3DView (away3d init) > > Away3DMediator (Listening for notifications - turn lights on or off etc) > > Away3DCameraView (camera init) > > Away3DCameraMediator (Listening for camera notifications: lookat > > number3D/vector/object3d etc) > > Away3DRenderer (rendering on enter frame) > > Away3DRednererMediator (Listening for notifications - enable / disable > > rendering the view) > > Away3DCubeView (just a cube of default size and at a fixed location) > > Away3DCubeMediator (Listening for notifications: collision) > > Away3DSphereView (just a sphere of default size and at a fixed location) > > Away3DSphereMediator (Listening for notifications: collision) > > > > If you click the cube a notification is sent which the camera mediator > > picks up and tweens to look at the cube, same for the sphere. > > Now if I was to process logic requiring the monitoring of 2 or more > objects > > in the scene, where would this logic be placed? In the good practises > > documents I've read for each of the frameworks it is recommended that a > view > > manage another's view. If I was not using these frameworks and my usual > > simple modular based design comprising of singleton, factory & observer > > patterns I would do all this in the renderer, breaking it down into > multiple > > classes as 1 to many child classes for managing each specific task. > > eg: I wouldn't use the case statement for the code below, I would do it > all > > in 1 file but to example if I had many many things to check and at > different > > times in a larger application. > > Away3DRenderManager.as > > private var _collision:Boolean = false; > > private function render(e:Event):void > > { > > Switch (mode) > > { > > case "check collision between cube 1 and cube 2": > > _collision = new Away3DRenderCubeCollisionCheck(cube1,cube2); > > break; > > // Lots more case statements calling various different classes > for > > their specific functionality all on 1 enter frame > > } > > //Code to animate cubes > > view.render(); > > } > > > > Away3DRenderCubeCollisionCheck.as > > private function Away3DRenderCubeCollisionCheck(cube1,cube2):Boolean > > { > > // Collision code > > return boolean; > > } > > > > > > What's your thoughts on this? > > > > Any of you got an example or willing to cook up a quick RobotLegs example > > using Away3D to collide 2 cubes and on collision reverse their direction? > > Thanks > > Darcey >
