Re: Core Data with OpenGL
On Mon, Oct 12, 2009 at 11:30 PM, Richard Somers rsomers.li...@infowest.com wrote: So you are saying that I should abandon this and put the draw method somewhere else like in a controller. Perhaps you could fill the picture in a little more for me. So far I have yet to find any sample code that is a document based core data application that uses OpenGL. There is no strictly correct way of solving your problem. Below are my recommendations. Design your model objects as data containers. Hence no drawing behavior in model objects. If you add behavior to your model objects, make minimal assumptions about the world outside the model objects. Have separate classes that know how to draw your model objects in a particular rendering technology. For OpenGL, have a custom NSOpenGLView class that knows how to translate your model objects to OpenGL commands. Create a controller class that acts as a resource manager. Make the controller decide when to allocate an OpenGL context, how many of them to have around, how the contexts are associated with the views, and generally make it orchestrate the whole thing. If your design does not fit this model well, then consider changing your design. /Dado ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data with OpenGL
For a variety of reasons, I use Core Data with OpenGL all of the time. One of my presentations this weekend at Voices That Matter: iPhone Developers Conference uses a Core Data application with two different Views as an example of the MVC design pattern. One View presents information about the Model using Core Graphics/Quartz. The other View presents information using OpenGL ES. I think that the Core Data model and any generated classes should be left untouched because you may want to regenerate the classes later. I use Categories to add View specific drawing methods to the objects that represent Core Data entities. There are different categories with different methods in each View. E.g. there are -drawInOpenGLContext: methods added to entity objects within the OpenGL View subsystem and there are -drawWithCoreGraphics methods added in the Core Graphics View subsystem. There is ample precedent for adding View specific capabilities to Model objects via categories. AppKit adds string drawing methods to NSString. You definitely don't want your View subsystem constantly asking Model objects what kind they are in order to present information. If you have ifs or switches based on the class of objects or even based on an attribute of an Entity, you are doing it wrong. It is much cleaner to use the built in language polymorphism. Just keep View related code implementation within the View. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data with OpenGL
On Oct 13, 2009, at 9:58 AM, Erik Buck wrote: I think that the Core Data model and any generated classes should be left untouched because you may want to regenerate the classes later. I use Categories to add View specific drawing methods to the objects that represent Core Data entities. I like this idea even more. Very good point about regenerating the representative classes behind entities - a separate category for drawing neatly segregates things. Maybe a good radar incident will see the Sketch example updated. -- I.S. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data with OpenGL
On Mon, Oct 12, 2009 at 7:47 AM, Richard Somers rsomers.li...@infowest.com wrote: Any suggestions or comments? This is typically where the controller layer would come in. A controller-layer object would know of the GL context and of the insertion/removal of objects in the MOC, and create resources accordingly. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data with OpenGL
On Oct 12, 2009, at 1:17 PM, Rob Barris wrote:
Within a single thread of execution, if you are about to do some GL
drawing and you are unsure of the current context, you should set
it, and it will stay set.
If I knew what it was I could set it. My model object knows nothing of
the glContext. Also I do not think storing the context in the model is
appropriate. That would seem to violate the MVC design pattern.
(Although having the draw method in the model class is technically a
violation of MVC but one that seems to be generally accepted and
necessary.)
I think Kyle Sluder's remarks of putting the OpenGL resource creation
and disposal stuff in the controller-layer might be the way to go. I
am currently using off the shelf NSObjectController and
NSArrayController classes to add and remove model objects from the
managed object context. I could subclass these and put the OpenGL
resource code in there.
My model object code looks something like this.
@interface ModelObject : NSManagedObject
{
// OpenGL resource objects needed to draw the model object
...
}
@end
@implementation ModelObject
- (void)awakeFromInsert
{
[super awakeFromInsert];
[self prepareOpenGL];
}
- (void)awakeFromFetch
{
[super awakeFromFetch];
[self prepareOpenGL];
}
- (void)didTurnIntoFault
{
[self cleanupOpenGL];
[super didTurnIntoFault];
}
- (void)prepareOpenGL { ... }
- (void)cleanupOpenGL { ... }
- (void)draw // current glContext set by the caller
{
// Draw to OpenGL context.
...
}
@end
Thanks for your help and comments.
Richard
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Core Data with OpenGL
On Oct 12, 2009, at 4:27 PM, Ben Trumbull wrote: but in this case it must draw itself. No, it doesn't must do anything. Views draw themselves, model objects are state, and controllers are intermediaries. ... What problem are you trying to solve by knowingly violating the MVC design patterns ? Hmmm ... must draw itself? No, from a pure MVC approach, I agree with you 100% that not only does it not must but it shouldn't. However, it's only fair to point out theSketch example - the quintessential example for drawing applications. The STKGraphic class has draw...InView: methods. For a drawing app, I can see why it might be considered a cleaner design, despite knowingly violating the MVC design patterns. A Shape knows how - and where - to draw itself - just give it a view. I think it's mostly a matter of personal taste and methodology but it certainly isn't wrong, which I suppose is why it's now one of the few examples left in the developer examples folder in Snow Leopard. In theory this violates MVC, but in practice this design approach is much easier to understand and maintain (in my opinion, anyway) for a drawing application like Sketch. This isn't meant to contradict your overall advice, but I do think an application's architecture doesn't have to *rigidly* adhere to any one design pattern to be good. -- I.S. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data with OpenGL
On Oct 12, 2009, at 2:27 PM, Ben Trumbull wrote: It sounds like you're trying to create a tight 1:1 binding between your model objects and controller objects to avoid actually writing a controller layer. That may be the case. I am currently using an off the shelf NSObjectController and NSArrayController. This is hard, because you're going in the wrong direction. Put a stake in the ground, that your model objects will never ever call directly into OpenGL. I have a collection of model objects in a core data store. I enumerate all the objects in the store one by one and draw them. It seems only natural to have the draw method in the model object class. (There are several examples of sample code from Apple and others where the draw method is implemented in the model object.) So you are saying that I should abandon this and put the draw method somewhere else like in a controller. Perhaps you could fill the picture in a little more for me. So far I have yet to find any sample code that is a document based core data application that uses OpenGL. Richard ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
