Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Thor 2.0 released!  (Read 346720 times)

0 Members and 1 Guest are viewing this topic.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #75 on: May 05, 2012, 12:09:26 pm »
Yesterday, I pushed the new thor::MultiResourceCache class. Meanwhile, the tutorial for Thor.Resources has been updated, too.

Quote from: exploit0r
Although it means I'll 'have to' refractor my application. ::)
You only have to change thor::ResourceCache<X> to thor::MultiResourceCache, the interface is exactly the same ;)

Quote from: fallahn
IOne thing that struck me though was that I felt it was a bit inflexible to render particle systems to a RenderWindow only
Hehe, I have planned to derive the thor::ParticleSystem from sf::Drawable, too. At the beginning of Thor, I didn't like this approach, because sf::Drawable contained many methods like GetPosition() that were useless for particles, but now the situation has changed.

By the way, am I supposed to just ignore the sf::RenderStates::texture attribute and to override it with the specified particle texture?
« Last Edit: May 05, 2012, 12:17:51 pm by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Thor 2.0
« Reply #76 on: May 05, 2012, 01:01:25 pm »
Quote
By the way, am I supposed to just ignore the sf::RenderStates::texture attribute and to override it with the specified particle texture?
Yes :)
Laurent Gomila - SFML developer

fallahn

  • Sr. Member
  • ****
  • Posts: 495
  • Buns.
    • View Profile
    • Trederia
Re: Thor 2.0
« Reply #77 on: May 05, 2012, 05:51:00 pm »
I was just wondering - is it possible to tie emitters to particles? For example if I wanted to explode a vehicle could I use a particle system to emit 4 or 5 particles as 'chunks' of the vehicle, then have each of those particles emit their own smoke and flame? Perhaps this is a reason to use GetPosition() on particles? :) I really like the idea of Distributions by the way, I've created some really good looking (if I say so myself ;) ) smoke effects this afternoon

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #78 on: May 05, 2012, 06:45:46 pm »
Recursion is currently not possible. You could add 4 or 5 emitters, which emit a single chunk once at beginning, and smoke/fire over time. I'm also planning an option for user-specific data per particle, that should help in many situations. I'm considering aurora::CopiedPtr<void> for this.

Good to hear that you like the distribution concept! How did you use the distributions, did you define own ones?


There is now a progress list on my homepage that shows the features that are planned for version 2.0 and 2.1. It is not definitive, but you should be able to get a rough overview about what's planned :)
« Last Edit: May 05, 2012, 07:50:54 pm by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

fallahn

  • Sr. Member
  • ****
  • Posts: 495
  • Buns.
    • View Profile
    • Trederia
Re: Thor 2.0
« Reply #79 on: May 05, 2012, 09:20:43 pm »
OK, I shall have a think about how I might do it. I didn't define any of my own distributions (yet) but I like the concept - it's a great way to quickly and easily add variations to a particle system. It definitely beats any of my personal solutions which would involve things like
#define RANDOM_SPREAD rand() % screenWidth, rand() % screenHeight
(ok not a great example but you see what I mean) which I'd normally come up with - I'm a C programmer really, mainly doing embedded software and I'm using SFML to write *fun* things and learn C++ :)  It's a very elegant solution.

fallahn

  • Sr. Member
  • ****
  • Posts: 495
  • Buns.
    • View Profile
    • Trederia
Re: Thor 2.0
« Reply #80 on: May 08, 2012, 05:06:04 pm »
I've been thinking about passing RenderStates via the draw method, and I thought maybe it would be better to pass a pointer to a RenderStates object at construction of a particle system (like you currently do with a texture). That way you can set the texture/blendmode/shader once for the whole particle system, and don't have to worry about overriding the texture when drawing. For instance I use BlendAdd for fire particles, BlendMultiply for a smoke particle system and I could also create a system with a glow shader for making lasers and things. Just an idea.

I'm going to try deriving my own affector tonight too... I had an idea for one which scales particles based on their velocity so slower particles look smaller and therefore further away - a kind of fake 'depth' effect.  We'll see how it goes :)

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #81 on: May 08, 2012, 05:53:24 pm »
OK, I shall have a think about how I might do it. I didn't define any of my own distributions (yet) but I like the concept - it's a great way to quickly and easily add variations to a particle system.
True, it gets especially interesting in combination with lambda expressions:
emitter->setParticleRotation( [] () { return anyValue; } );

I've been thinking about passing RenderStates via the draw method, and I thought maybe it would be better to pass a pointer to a RenderStates object at construction of a particle system (like you currently do with a texture). That way you can set the texture/blendmode/shader once for the whole particle system
That's not a bad idea, however the current draw() method has the advantage that I can keep the sf::Drawable inheritance and therefore integrate thor::ParticleSystem better with SFML. I don't know however how users want to use the particle system, but probably rather the way you describe.

and don't have to worry about overriding the texture when drawing.
The texture specified with sf::RenderStates is ignored. By the way, that might also be a small indicator that there is a better approach. Also the sf::RenderStates::transform attribute is questionable, since my particle system doesn't represent a 2D entity.

What's the usual idiom to create own drawable objects with custom shader or blendmode? I thought sf::Drawable was made for exactly this stuff, but now I'm confused :-\
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Fugan

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: Thor 2.0
« Reply #82 on: May 08, 2012, 06:17:41 pm »
As an extension of the event system and custom actions, what about creating a simple console? I envision something that you can bring up on screen and type commands. The console class would parse the input, then go to a data structure that contains all the commands. Commands would basically be a function pointer with a string for the command name.

You implement your own custom commands, then push command objects onto the console. I think it would be really useful for people to be able to quickly add a command console to their game, rather than using key code combinations or other stuff when testing. It would also promote better software design, since people wont be tempted to "hack" something into their code to test some aspect of their game, since they can write a console command class instead.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Thor 2.0
« Reply #83 on: May 08, 2012, 06:45:56 pm »
Quote
What's the usual idiom to create own drawable objects with custom shader or blendmode? I thought sf::Drawable was made for exactly this stuff, but now I'm confused
States that make sense at the object level are usually set in its public API, stored as members and used in draw(), overwriting the user supplied states.
Other states are just passed to the RenderTarget::draw function and produce the expected result.

So, if it makes sense for a particle system to define a blend mode, just add setBlendMode/getBlendMode in the corresponding class and use that in your draw().

To me, the only thing that is not clear is how states should be applied when both the object and the user provide explicit values for them. The transform is combined, which seems like a intuitive behaviour, but for blend mode, texture and shader, maybe it would be more intuitive the other way round, ie. if the user supplied states override the object states? Note that it would be more complicated to apply (how to know if a state is a default value, or has explicitely been set by the user?).

If you have other ideas, I'd be glad to discuss them, but don't forget that any design modification won't happen before SFML 3 :)
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #84 on: May 08, 2012, 08:17:55 pm »
As an extension of the event system and custom actions, what about creating a simple console?
"Extension" is an understatement, a console is a full-fledged interactive GUI element ;)

It is an interesting feature, but as a GUI element, it is quite specific: I need to define a graphical layout (colors, font, metrics), the user's events must be caught, and a tiny parser interprets the input. I find it too complex for Thor at the moment, but maybe I'll think about it again in the future. Thanks for the suggestion!

Otherwise, what do you think about the Events module? Have you already looked at the generic thor::EventSystem, do you consider it useful? It works similar as a restricted Boost.Signals, in case you know this library.


So, if it makes sense for a particle system to define a blend mode, just add setBlendMode/getBlendMode in the corresponding class and use that in your draw().
I haven't questioned the current SFML approach yet, but it looks like I'll have enough time until SFML 3 ;)

How the sf::RenderStates attributes behave in my concrete use case:
  • texture: Attribute of the particle system, thus overridden
  • transform: Not very meaningful, because the system itself is no transformable entity. One can indirectly transform the particle vertices though, but is this useful...?
  • shader/custom blend modes: No idea, I haven't used them a lot yet. But fallahn's point sounds right: One probably wants the particles to be drawn with the same shader/blend mode again and again.
It looks like single attributes might be more convenient, but I'm sure that if I change this, tomorrow there's another user requesting an SFML-compatible interface taking sf::RenderStates :P
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Thor 2.0
« Reply #85 on: May 08, 2012, 08:27:42 pm »
Quote
transform: Not very meaningful, because the system itself is no transformable entity.
Does this mean that I can't attach a smoke particle system to a car, for example? Or is it handled differently (ie. you can transform the emitter)?

Quote
shader/custom blend modes: No idea, I haven't used them a lot yet. But fallahn's point sounds right: One probably wants the particles to be drawn with the same shader/blend mode again and again.
I don't think that shaders are a specific attribute of particle systems, but blend mode would totally make sense. It's quite common to use a multiply or add blend mode with particles.

Quote
It looks like single attributes might be more convenient, but I'm sure that if I change this, tomorrow there's another user requesting an SFML-compatible interface taking sf::RenderStates
For shaders, probably. But the blending mode is really a property of the particle system: I can't see any use case where it would have to be chosen at draw time.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #86 on: May 12, 2012, 11:21:06 am »
Does this mean that I can't attach a smoke particle system to a car, for example? Or is it handled differently (ie. you can transform the emitter)?
Yes, I intended the emitter to be a transformable entity. Like this, e.g. a plane can have a single particle system (one smoke texture), but two emitters with different positions and smoke emission directions.

However, the emitters currently don't have a draw() method, the whole transformations are purely logic-based. That is, particles have a global position etc. Physics (like repelling particles) and general interactions with the environment should be easier to handle this way.

But I know, there should be a possibility to attach an emitter to an object. I've even thought about a scene graph, but there are currently too many questions open. The current approach is:
auto emitter = thor::UniversalEmitter::create();
emitter->setParticlePosition( [&] () { return object.getPosition(); } );
emitter->setParticleVelocity( [&] () { return -object.getVelocity(); } ); // towards rear

Something that would be nice were:
auto emitter = thor::SceneEmitter::create(object); // Take object as parent
But I think only position, rotation and scale would be taken from the parent object. Although it might be handy to adapt also velocity, I think it's difficult to allow this in a general way...

Originally I've even planned to use sf::Transform, but since it is expensive and ambiguous to extract the single transform components, I've left the direct position/rotation/scale.

Any ideas concerning this are very welcome :)


For shaders, probably. But the blending mode is really a property of the particle system: I can't see any use case where it would have to be chosen at draw time.
Ok, so you suggest to provide corresponding get/set methods and ignore the sf::RenderStates::blendMode attribute in ParticleSystem::draw()?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Thor 2.0
« Reply #87 on: May 12, 2012, 12:25:32 pm »
Quote
But I know, there should be a possibility to attach an emitter to an object.
When I say "attach to an object" I simply mean "have a way to set the same transform as the object". Really attaching to an object is another subject, and yes it's probably not easy to design without a scenegraph-based world.

Quote
Ok, so you suggest to provide corresponding get/set methods and ignore the sf::RenderStates::blendMode attribute in ParticleSystem::draw()?
Yes.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #88 on: May 19, 2012, 08:30:12 pm »
Another big step is taken: The fundament of the new Animation API. I have reflected quite a long time on how to make everything more flexible without adding unnecessary complexity. I've come to the conclusion to diverge from the shared-ownership and inheritance approach, towards generic functors.

The core part is still thor::Animator, it has become a class template.
template <class Animated, typename Id>
class Animator;
  • Animated is the class that is being animated, for example sf::Sprite. Now it is possible to animate also other classes, like sf::Text or sf::Shape; even classes are not related to sf::Drawable at all.
  • Id is the identifier type to distinguish the stored animations. Up to now, std::string has been enforced, now there can be any comparable type, such as an enum.
The class thor::Animation was removed, there is no inheritance hierarchy anymore. The concrete animation class thor::FrameAnimation is now a functor with a templated operator(). The template parameter Animated can be any class supporting setTextureRect(). Mostly, this will be sf::Sprite.
template <class Animated>
void operator() (Animated& animated, float progress) const;

In fact, everything that can be called with an object reference and a float is now an animation. This includes normal functions and lambda expressions. For instance, it requires a single line to define an animation reverse that plays another animation anim backwards:
auto reverse = [anim] (sf::Sprite& s, float pr) { return anim(s, 1.f - pr); };
(Imagine the amount of code for the same functionality with a traditional java-style class hierarchy)

Code that has looked like this:
thor::FrameAnimation::Ptr explosion = thor::FrameAnimation::create();
explosion.addFrame(1.f, sf::IntRect(...));
explosion.addFrame(1.5f, sf::IntRect(...));

thor::Animator animator;
animator.addAnimation("expl", explosion, sf::seconds(3));
now looks like this:
thor::FrameAnimation explosion;
explosion.addFrame(1.f, sf::IntRect(...));
explosion.addFrame(1.5f, sf::IntRect(...));

thor::Animator<sf::Sprite, std::string> animator;
animator.addAnimation("expl", explosion, sf::seconds(3));
The module is currently quite small, I have planned to add more animations (such as color gradients) as well as operational primitives (reverse, concatenate). However I'm not sure how much of this will be done before 2.0.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Klaim

  • Full Member
  • ***
  • Posts: 137
    • View Profile
Re: Thor 2.0
« Reply #89 on: May 23, 2012, 04:33:10 pm »
Hi I just wanted to point this discussion where I suggested an additional library to SFML and Laurent thinks (and I agree) that it would be a good addition to Thor : http://en.sfml-dev.org/forums/index.php?topic=8010


By the way, do you plan to change the website soon? The textures and colors are really agressive for my eyes...