Glowing Ball Tutorial

edited February 2015 in General discussions
Hi everyone,

I've just finished a new tutorial for creating a natural-looking glowing ball. I'd love to have your feedback about it, and I'd like to add it to the community tutorials if you think it's fine.

Cheers!

Comments

  • edited March 2015
    Really nice tutorial, congrats! =)

    There's only one detail that I feel would be nice to address (but not really a must to): you seem to rely on the creation order for the rendering order but that is not really a good option.

    It used to be deterministic in the past, but orx has since been modified to internally keep the objects sorted in the same order as their spatial location in memory banks. This has been changed to improved cache friendliness when iterating through their collection, in situations where a lot of objects would dynamically be created and deleted (someone said particles?).

    So the best option is to always control the rendering order, either by using Z coordinates or explicit object groups: it won't make a difference in simple examples, however it might prevent some headaches in more complex setup with intermittent "visual glitches".

    Bonus option: one could create the negative texture on the fly when a tagged "glow" texture gets loaded. It's of course a trade off between execution speed and offline pre-work and it's up to users to pick their own depending on their use case, but it might maybe be interesting to mention that such an option is available.
  • edited March 2015
    Pretty nice looking tutorial. Good job!
  • edited March 2015
    sausage wrote:
    Pretty nice looking tutorial. Good job!
    iarwain wrote:
    Really nice tutorial, congrats! =)
    Thanks :) and thanks for the feedback.

    So the best option is to always control the rendering order, either by using Z coordinates or explicit object groups: it won't make a difference in simple examples, however it might prevent some headaches in more complex setup with intermittent "visual glitches".

    Wow, I think this is very important. Probably not very essential to what the tutorial is describing, but very important nevertheless.

    Maybe I don't understand how to use object groups correctly,but I feel that they don't play nicely with objects that are supposed to be in the same "scene". I mean it's clearly perfect to separate game objects vs. GUI components, but you can't really use them to order game objects among each other, can you?

    For instance, in the specific example of this tutorial, I have two objects with a definite order, so I could try to put the additive element into an "additive" object group, and likewise for the multiplicative. Then I could specify their order in the camera section. But what would happen if two glowing balls overlapped? The drawing orders of their respective additive and multiplicative components will then probably be: Multiplicative1 -> Multiplicative2 -> Additive1 -> Additive2, and the result of this order will be different from the correct order, which is: Multiplicative1 -> Additive1 -> Multiplicative2 -> Additive2.

    So I guess the only choice is to use the Z distance. What's your recommendation on that? should I separate the additive and multiplicative components using a small, arbitrary distance like 0.0001, and hope nothing comes in between?
    Bonus option: one could create the negative texture on the fly when a tagged "glow" texture gets loaded. It's of course a trade off between execution speed and offline pre-work and it's up to users to pick their own depending on their use case, but it might maybe be interesting to mention that such an option is available.

    You're right, I should probably mention that. I've omitted it for simplicity, but a sentence wouldn't hurt. I was actually also thinking about maybe using the exact same texture but with a custom shader that does the negation. That would simplify the code, and might not add much overhead, since the regular texture is also applied with a shader anyway.
  • edited March 2015
    Wow, I think this is very important. Probably not very essential to what the tutorial is describing, but very important nevertheless.

    Maybe I don't understand how to use object groups correctly,but I feel that they don't play nicely with objects that are supposed to be in the same "scene". I mean it's clearly perfect to separate game objects vs. GUI components, but you can't really use them to order game objects among each other, can you?

    Groups are definitely not tailored to do "micro-ordering". As you said they're more intended for "macro-ordering", separating background, middle ground and foreground as well as pickable layers.
    For instance, in the specific example of this tutorial, I have two objects with a definite order, so I could try to put the additive element into an "additive" object group, and likewise for the multiplicative. Then I could specify their order in the camera section. But what would happen if two glowing balls overlapped? The drawing orders of their respective additive and multiplicative components will then probably be: Multiplicative1 -> Multiplicative2 -> Additive1 -> Additive2, and the result of this order will be different from the correct order, which is: Multiplicative1 -> Additive1 -> Multiplicative2 -> Additive2.

    Yep, that's what would happen, however you can still separate the background group from the glowing ball ones. You'd need to rely on Z coordinates for the balls themselves.
    However you'd get the full Z range within a single group, whereas if you were to have all your objects inside the same group, they'd all have to fit inside the same Z range.
    For example, if we have:
    [Camera]
    GroupList = Background # Glowing Ball
    FrustumFar = 1
    
    [O-Back]
    Group = Background
    Position = (0, 0, 0.1)
    
    [O-Ball]
    Group = Glowing Ball
    Position = (0, 0, 1.0)
    

    Even if O-Ball has a Z greater than O-Back's, it'll still get rendered on top of it as group rendering do not overlap.
    So I guess the only choice is to use the Z distance. What's your recommendation on that? should I separate the additive and multiplicative components using a small, arbitrary distance like 0.0001, and hope nothing comes in between?

    That's usually what I do, yes. I set the child object with a relative position containing the correct Z offset, and make sure I always use bigger offsets between regular objects. Now if you know that you'll never have two glowing balls potentially overlapping, there's no need to care about this at all, of course.
    You're right, I should probably mention that. I've omitted it for simplicity, but a sentence wouldn't hurt. I was actually also thinking about maybe using the exact same texture but with a custom shader that does the negation. That would simplify the code, and might not add much overhead, since the regular texture is also applied with a shader anyway.

    Yep, custom shader is definitely the easiest method and in this case its cost won't make any difference even for large surface objects. However it also means that the user is comfortable with writing their own pixel shaders, and that's not always the case. It can be a good first contact though. :)
  • edited March 2015
    Thanks for your reply Iarwain, I could only now find the time to apply your suggestions. I've modified the tutorial to add proper Z-based ordering of the additive and multiplicative components. I've also extended the tutorial with a bonus section that describes how to obtain the negative texture using a shader.

    I've now added a link to the community tutorials section pointing at this tutorial :)
  • edited March 2015
    Nice work! I'll add a news on the site with a link to your tutorial if you're ok with this.
  • edited March 2015
    Sure, I'm glad you've found it newsworthy :)
  • edited April 2015
    Yep, sorry, I've been longer than expected, I'll post a news this week end about your tuto as well as Knolan's editor. :)
Sign In or Register to comment.