procedurally generated objects and textures

edited July 2012 in Help request
Hi!

I've a humble bundle of questions under the theme "procedural generation" :). So, the purpose is to be able to generate objects with procedurally generated textures (and probably other properties too).

1) Is orxObject_create() supposed to be used by orx users, is it equivalent to orxObject_createFromConfig() with an object section without any specified fields?

2) What is orxOBJECT_GET_STRUCTURE()? Is it the proper way of accessing the orxGraphics of an orxObject? Does it have any uses since it's not specifically called orxOBJECT_GET_GRAPHICS (or even why not orxObject_GetGraphics()?)

3) I don't see any way of setting the orxGraphics of an orxObject, does that mean every orxObject is created with it's own orxGraphics, and that I have to work on it, instead of setting a new one?

4) When two objects are created from the same config section, what do they share? Their orxGraphics', their orxTextures or just their orxBitmaps?

5) I feel that a similar dark magic is going on as in Q2, when you're accessing the orxTexture of an orxGraphics. Is there a way to figure out what's happening when some function is returning an orxSTRUCTURE *? BTW, it there a technical jargon for this kind of data management, so that I can read about it?

6) How can I set the orxBitmap of an orxTexture? Is it through orxTexture_LinkBitmap? Why is it called to "link"?

7) When I use orxDisplay_SetBitmapData, what's happening? Is the bitmap storing the pointer I pass to it, or is it copying the contents? If it's storing the pointer, who has the ownership of that data buffer? (i.e, will the orxBitmap delete the buffer while it's being deleted?)

Sorry for this long list of questions, I've been trying to figure these out myself, but I've many hypotheses about how things might be working based on possible answers to these questions, and the permutations explode in my mind...

Thanks for your patience in advance :)

Comments

  • edited July 2012
    enobayram wrote:
    Hi!

    I've a humble bundle of questions under the theme "procedural generation" :). So, the purpose is to be able to generate objects with procedurally generated textures (and probably other properties too).

    Let's do it! :)
    1) Is orxObject_create() supposed to be used by orx users, is it equivalent to orxObject_createFromConfig() with an object section without any specified fields?

    Well you can call it for sure but you're not encouraged to for the sake of easiness. You won't exactly have the same by calling the Create() than by calling the CreateFromConfig() with an empty section.
    The differences are that:
    - the object will have a name
    - an orxFRAME will be created and initialized in the config case and placed in the scene graph
    - the orxFRAME that has been created will be automatically freed when the object gets deleted
    2) What is orxOBJECT_GET_STRUCTURE()? Is it the proper way of accessing the orxGraphics of an orxObject? Does it have any uses since it's not specifically called orxOBJECT_GET_GRAPHICS (or even why not orxObject_GetGraphics()?)

    An object is an abstract container by itself and knows nothing about what it contains except that they are orxSTRUCTURE derivatives. It's a classic DOD (Data Oriented Design) component architecture.

    The whole orxObject_* API has then been extended for convenience sake when in need of interacting with properties of those components.

    orxOBJECT_GET_STRUCTURE() is merely a convenience wrapper. You can access a component stored on an orxOBJECT like these:
    orxGRAPHIC *pstGraphic = orxGRAPHIC(_orxObject_GetStructure(pstObject, orxSTRUCTURE_ID_GRAPHIC));
    
    orxGRAPHIC *pstGraphic = orxOBJECT_GET_STRUCTURE(pstObject, GRAPHIC);
    

    Up to you and those are exactly the same. If you look at the definition of orxSTRUCTURE_ID in orxStructure.h, you can see which structures can actually be stored in an orxOBJECT and which ones can't.
    The way it's currently defined means adding new component structures doesn't come with the need of modifying the orxObject API to access them (which would be the case with explicit naming such as orxOBJECT_GET_GRAPHIC/orxObject_GetGraphic).
    3) I don't see any way of setting the orxGraphics of an orxObject, does that mean every orxObject is created with it's own orxGraphics, and that I have to work on it, instead of setting a new one?

    If you create an object from config and that section has a graphic properties, then your object comes with an orxGRAPHIC, otherwise it won't.

    You can link/unlink components by using orxObject_LinkStructure()/orxObject_UnlinkStructure(). If the component was created by orx internally, then orx will delete it when no one references it anymore (orx keeps the ownership). If you create a component, you'll be in charge on deleting it (you keep the ownership).

    All orxSTRUCTURE derivatives are reference counted.
    4) When two objects are created from the same config section, what do they share? Their orxGraphics', their orxTextures or just their orxBitmaps?

    They won't share anything directly, which means all their components will be unique.
    However, behind the scene, the textures will be shared at the orxTexture module level (working with an internal database), it's just transparent for callers of that module.
    To be more precise, the name itself will also be shared, at the orxConfig module level making sure the actual config section can't be completely deleted from code.
    5) I feel that a similar dark magic is going on as in Q2, when you're accessing the orxTexture of an orxGraphics. Is there a way to figure out what's happening when some function is returning an orxSTRUCTURE *? BTW, it there a technical jargon for this kind of data management, so that I can read about it?

    Well, the whole abstraction is made on purpose, not sure about technical jargon as I usual hate those. :)

    Right now orx only handles 2D so an orxGRAPHIC can only contain an orxTEXTURE. But the whole code has been written to allow different type of data in the future where an orxGRAPHIC won't always contain an orxTEXTURE but probably something like an orxMESH, orxSKELETON or who knows else! :)

    You have the orxStructure API to query what a structure actually is and doing "safe" casts, in a cheap RTTI way, if you need any runtime validation.
    I guess a wiki page on the relation between all types of orxSTRUCTUREs would be nice.
    Usually users don't really care as they don't meddle with behind the scene stuff that's why there isn't much about that topic in the forum.
    6) How can I set the orxBitmap of an orxTexture? Is it through orxTexture_LinkBitmap? Why is it called to "link"?

    Yep, orxTexture_LinkBitmap.
    Link means a few things, first than you should symmetrically Unlink what has been linked, always. It also means that there will be reference counting behind the scene, so even if you have the ownership of a structure and you revoke it, the structure will then be owned by the linker till an unlink happens. Same idea with orxObject_LinkStructure().
    7) When I use orxDisplay_SetBitmapData, what's happening? Is the bitmap storing the pointer I pass to it, or is it copying the contents? If it's storing the pointer, who has the ownership of that data buffer? (i.e, will the orxBitmap delete the buffer while it's being deleted?)

    The bitmap is copied to a texture held in GPU memory, in a synchronized fashion. That means that whenever the call returns, you can do whatever you want with your buffer, orx won't be accessing it anymore.
    There isn't any bitmap buffer held by orx in CPU memory, everything is stored on the OpenGL server side.
    Sorry for this long list of questions, I've been trying to figure these out myself, but I've many hypotheses about how things might be working based on possible answers to these questions, and the permutations explode in my mind...

    Thanks for your patience in advance :)

    Not at all, it's actually a great thing as others might want this info later on and there'll at least now be some traces in the forum. :)

    I also believe that gemberkoekje started the reference section of the wiki with similar questions in mind, if you ever want to contribute to it. :)

    I'm happy to answer any questions anyway, I believe support is something very important and it's usually fun to do, at least for me. :)

    Now if you want to see how I'd handled procedurally generated textures, you can look at the (very simple) examples of the shader/lighting tutorial (#12) where I create normal maps on the fly and the compositing one where I create some textures for the sake of not having external resource to use beside config.
Sign In or Register to comment.