Hi all,

This question might be better off posted in iDevApps but I don't have an account there, and

1. I couldn't be bothered to create an account over there.
2. My app will be game development based, so I'm going to roll with it here and see what feedback I get

For my own amusement and in a concerted effort to learn Cocoa (again) I want to write a Cocoa App. I've worked through most of Aaron Hillegass' great book, but never actually built my own fully featured Cocoa App. I also want to leverage CoreData because frankly it seems really really cool. The trouble is the tutorials I have seen on Apple's site, and CocoaDevCentral are all well and good, but I can't really figure out how to go about leveraging it for the type of application I want to make.

I want to write something like a Game Editor or Asset Conditioning tool. The idea would be to load source assets (.obj or .fbx files for example) mess with their materials (shaders / textures), perhaps perform mesh processing on them and then convert them into a more game friendly format. Thats the general idea anyway.

The trouble I'm having is trying to figure out how some of Classes I'd have in a traditional C++ or Obj-C app might map to CoreData Entities and Attributes. For something like a Material I've got a pretty good idea how I would represent that as an Entity. But for a mesh I'm not so sure.

Lets just say for the sake of argument that in it's simplest form a mesh is a set of vertices, a set of indices and an associated material.

One way to represent a mesh as an Entity would be to have 3 attributes, one for each of the three components. Easy.... Well for material it is, that could simply be an integer index into an array of materials. However for the other two attributes it's not so clear. Taking the more complex of the two 'vertices' you can't easily represent a set of vertices as a single attribute. Attributes are generally simple things such as Integers, Floats, Strings & Dates. There are two others Binary Data and in Leopard (I think) a Transformable. These last two may be my best option, but they seem a lot more complex than the basic attribute types.

The other alternative that to my aging brain seems overkill would be to create a Vertex Entity with float attributes for position (x, y & z) normal, uv etc. Then for the Mesh entity have a one to many reference to Vertex. Actually thinking about this now doesn't actually seem as ludicrous as it did in the past. I guess I'm just concerned with performance. I guess if I'm only using the CoreData to persist data to disk and internally I can use some other representation of my data then there shouldn't be an issue with performance.

Maybe I've been thinking about CoreData all wrong and it's only just started to make sense writing this EMail.... Maybe I still don't have a clue, and I'm talking rubbish. Does anyone else have an opinion on this? I think half my trouble is I could write the basic app in C++ or even Obj-C without too much trouble but with CoreData I feel like I'm putting an awful lot of trust in a system that I don't fully understand.

Any opinions would be appreciated

Thank you

Claire

I don't think CoreData will be any help to you at all. It's mostly for getting persistence for free if you don't care about file format. You do care about file format, and don't much care about persistence.

Also, CoreData makes working with stuff like matrices and vertices really hard. I just don't think it's suitable for the task.

YMMV, and others may have other opinions

I tried leveraging CoreData for games once (a game/3d "editor" too), but I gave up early since it soon seemed that it wasn't a really good fit. As I (somewhat vaguely) recall, it seemed like I found myself being forced into writing the game so that it fit CoreData's way of doing things, and I didn't want to commit to that.

I'm still not convinced that CoreData would be bad to use for a game or editor, but I didn't have much luck with it myself.

I will say this though: Don't try to learn CoreData if you're trying to also learn Cocoa. Get some solid knowledge and experience built up with Cocoa first.

Well, now I don't feel so bad that I found out about CoreData after I finished my Text Editor.

I'm using Core Data for Chipmunk Playground, and I've found it pretty suitable. I love the fact that I have saving, loading and undos for free.

But now I'm working on improving the editor (making it more like a drawing app) and realising that you have to learn a lot to go slightly deeper, like binding to a custom view.

Seems to me that it wouldn't be very suitable for your app, unless you wanted to make more of a model library rather than just a viewer/converter. And then I'd just use Core Data to keep track of file paths and maybe material attributes, and deal with the rest yourself.

All very interesting replies, thank you

Well at least I'm not the only one struggling making CoreData fit what I'm trying to do

It may be that the level at which I'm trying to use CoreData is wrong.

Part of what has got me thinking about CoreData again is the Asset System / Pipeline we're building at work. The basic idea is to reference meshes / textures & shaders in a database via file paths. Material parameters would be contained directly in the Database which is essentially how maximile suggest I might use CoreData. So maybe using traditional methods for the lowlevel parts like Mesh manipulation and CoreData for higher level Librarian type functionality (if I decide I need / want it).

So my next question, can I freely mix standard Cocoa App functionality (saving, loading and perhaps Undo) with CoreData's method of working? I think Wil Shipley was talking about something similar on his blog recently so I assume you can. I guess the easiest thing to do would be create a new CoreData application but don't touch the CoreData side of things until I'm ready to add that level of functionality.

(I should probably point out, that I am simply wanting to use CoreData for the sake of it, because it's there and as a learning exercise as opposed to anything else.)

That could work, although it sounds like a lot of trouble, possibly more trouble than it's worth. Wil Shipley only implemented his own undo, and let's face it, Delicious Library is a rather simple application when it comes to data handling. In theory, all you need is to handle some files the normal way and some others using Core Data, which should be easy. I suggest you make a tiny test project to see whether this approach works as well as you hope.