Topics

1

SFML projects / Light and Shadow Volume Generation for Sprite Sheet Objects

« on: December 16, 2017, 06:13:17 am »

Hello, all.

This was my first semester of graduate school, and I took a computer vision course.  For my final project, I decided to try to develop a method to generate shadows for sprites without having to meticulously find every corner in the sprite myself.

I hadn't seen anything out there do this yet, though there is likely something out there somewhere.  I doubt this is novel.

The result is a paper I wrote, titled "Light and Shadow Volume Generation for Sprite Sheet Objects using Outline Mesh Generation".

In short, it uses Canny edge detection and contouring to generate the contour of objects in sprite sheets and extracts the coordinates of every point along the contour.
This contour is used as an occlusion mesh for casting shadows.

It seemed to work pretty well for the sprite that I initially tested it on.  It is not a ready-to-go framework, but it is a working sample implementation.  It uses SFML (well duh) and OpenCV (for the contouring).

I've source code here: https://github.com/JayhawkZombie/SpriteMeshLighting 

In there is also the paper, if you've interesting in reading more into it.


An image of a plain sprite:



What the sprite + shadow volumes looks like after extraction is finished:



I will probably get an actual framework/library up for generating these in a cleaner way soon (will update when I do so), but this was just a first working version.

2

SFML projects / Precompiled Libraries for Visual Studio 2017 (STATIC)

« on: July 11, 2017, 05:47:18 am »

I went ahead and pre-compiled SFML for Visual Studio 2017 for both Debug and Release, and both for targeting x86 and x64.
It is all using STATIC libraries, so the "Runtime Library" is set to "MTd" for Debug, and "MT" for release. "Basic Runtime Checks" are set to "Default", and "Preprocessor" contains "SFML_STATIC" as is needed for static linking.

The target platform is set to "10.0.15063.0" by default, but it will also compile if set to "8.1" if you aren't using Windows 10.  First thing you should change if you get errors is to check "Properties > Configuration Properties > General > Target Platform" and change it to 8.1 if you're not on Windows 10.

I've linked a zip with a VS solution pre-made to unzip and go.  The include paths are relative to the solution direction ("$(SolutionDir)/Dependencies/include") so there's no need to put the files in any "special" directory, and the linker is set up to find the lib files based on the configuration and target platform (also relative to the solution directory).

"SFMLTemplate/Dependencies" has "include" and "libs". "include" is obvious.  "libs" is split into "x86" and "x64" and each has "Debug" and "Release" with the appropriate libs.

The executables will be generated in the following location:
<Solution>/<TargetPlatform>/<Configuration>

So you'll end up with the exe in one of:
"SFMLTemplate/x86/Debug", "SFMLTemplate/x86/Release", "SFMLTemplate/x64/Debug", "SFMLTemplate/x64/Release"

depending on how how you are set up to compile.  "openal32.dll" is dropped in the top folder, so just copy it to wherever the executable is if you use the audio library.

The template contains a short program, basically the same as the tutorial app, and I've compiled it and run it on all 4 configurations and verified it works for both targeting the Windows 10 SDK and Windows 8.1 SDK.
Provided all is sound, you should just be able to unzip it, open it up in VS, compile it, and go.

Size is ~40MB compressed, 190MB uncompressed.
I hosted it on my dropbox, since I don't know if GitHub will appreciate uploading such a large directory.

https://www.dropbox.com/s/qe3e32rt3qymubv/SFMLTemplate.zip?dl=0

3

SFML projects / Procedural Lightning Effect Startup Animation

« on: April 12, 2017, 03:47:47 am »

Hey, all. 

I feel this just sort of looks cool, so I'll show it off to see what you think.
Here our engine is spelling out the letters "SFENGINE" by outlining the letters in lightning.  4 lightning bolts will strike 4 corners of the letters every frame, and then multiple lightning bolts will travel across the letters.  The 4 corner bolts will strike every 750ms until every letter has been hit, at which time it'll just go to the main menu.

While our engine is still in a baby state, we did recently add procedural lightning generation and lightning "storms" (really just probabilistic lightning bolt generation). 

The lightning will look similar every run (as it should), but the actual bolts are generated at runtime every time this is run so the bolts will never be identical.

After that we added a class to handle time-sequenced events with custom callbacks, a pretty simple group of 2 classes. 

  class SequenceNode
  {
  public:
    SequenceNode() = default;
    SequenceNode(const SequenceNode &Copy);
    SequenceNode(std::initializer_list<SequenceNode> Seq);
    SequenceNode(double delta,
                 std::function<void(void)> start,
                 std::function<void(void)> end);

    ~SequenceNode() = default;

    void TickUpdate(const double &delta);
    bool IsDone() const;

    void Start();
    void End();

  protected:

    double m_Duration;
    double m_CurrentDuration = 0.0;
    bool   m_IsDone = false;
   
    std::function<void(void)> m_StartCallBack = []() {};
    std::function<void(void)> m_EndCallBack   = []() {};
  };

and, of course, the class that actually queues up the nodes 

  class TimedSequence
  {
  public:
    TimedSequence() = default;
    ~TimedSequence() = default;

    void AddSequence(
      double Duration,
      std::function<void(void)> StartCB,
      std::function<void(void)> EndCB
    );

    void AddSequences(
      std::function<void(void)> Start,
      std::function<void(void)> End,
      std::initializer_list<SequenceNode> Nodes
    );

    void Start();
    void TickUpdate(const double &delta);
  protected:

    bool m_IsTiming = false;
    std::queue<SequenceNode> m_Nodes;
    std::function<void(void)> m_StartCallBack = []() {};
    std::function<void(void)> m_EndCallBack   = []() {};
  };

Whenever a sequence is started, a callback is called (if one was registered for that sequence node), and one is also called whenever that sequence node's duration has expired.  Here we are just using the m_StartCallBack function pointer, and for the second we just pass an empty lambda.

Then we can do this to create the sequence of callbacks, as well as the durations between them: 

  m_LightningSequence.AddSequences(
    [this]() {this->LightningSequenceStarted(); }, //CB for the lightning sequence starting
    [this]() {this->LightningSequenceEnded(); },   //CB for the lightning sequence ending
    {
      { 750.0, [this]() { this->LightningSequenceCB(0,  1,  2,  3, "S");  }, []() {} }, // 4 bolts strike the 'S' character
      { 750.0, [this]() { this->LightningSequenceCB(4,  5,  6,  7, "SF");  }, []() {} }, // 4 botls strike the 'F' character
      { 750.0, [this]() { this->LightningSequenceCB(8,  9,  10, 11, "SFE"); }, []() {} }, // 4 botls strike the 'F' character
      { 750.0, [this]() { this->LightningSequenceCB(12, 13, 14, 15, "SFEN"); }, []() {} }, // 4 botls strike the 'F' character
      { 750.0, [this]() { this->LightningSequenceCB(16, 17, 18, 19, "SFENG"); }, []() {} }, // 4 botls strike the 'F' character
      { 750.0, [this]() { this->LightningSequenceCB(20, 21, 22, 23, "SFENGI"); }, []() {} }, // 4 botls strike the 'F' character
      { 750.0, [this]() { this->LightningSequenceCB(24, 25, 26, 27, "SFENGIN"); }, []() {} }, // 4 botls strike the 'F' character
      { 750.0, [this]() { this->LightningSequenceCB(28, 29, 30, 31, "SFENGINE"); }, []() {} }, // 4 botls strike the 'F' character
    }
  );

After that, it's just a matter of telling the bolts that travel across the letters to start off and walk, so the "LightningSequenceCB" function is only a few lines long

void Level1::LightningSequenceCB(int Bolt1, int Bolt2, int Bolt3, int Bolt4, std::string ltext)
{
  m_LightningText.setString(ltext);
  m_BoltTopLeft.Spark(    { 0.f,    0.f },   m_BoltStrikePositions[Bolt1]);
  m_BoltTopRight.Spark(   { 1700.f, 0.f },   m_BoltStrikePositions[Bolt2]);
  m_BoltBottomLeft.Spark( { 0.f,    900.f }, m_BoltStrikePositions[Bolt3]);
  m_BoltBottomRight.Spark({ 1700.f, 900.f }, m_BoltStrikePositions[Bolt4]);

  m_CrawlBolts[Bolt1].Spark(m_LightningTraces[Bolt1]);
  m_CrawlBolts[Bolt2].Spark(m_LightningTraces[Bolt2]);
  m_CrawlBolts[Bolt3].Spark(m_LightningTraces[Bolt3]);
  m_CrawlBolts[Bolt4].Spark(m_LightningTraces[Bolt4]);
}

m_BoltStrikePositions is where the 4 bolts coming from the corners strike, which is just 4 chosen corners of the letters. 
m_LightningTraces contains the sequence of positions for the corners of the letters that we want each bolt to travel along. 

To update the sequence, all we have to do is call

m_LightningSequence.TickUpdate(delta);

The bolts themselves keep track of their lifetime, so we can call render on them even if they're supposed to be dead and they just won't draw.

The result is this (the word "SFENGINE" doesn't get rendered, but we're fixing that):

4

SFML projects / Additive v. Multiplicative Light and Shadow Blending

« on: March 11, 2017, 05:12:30 am »

I've been working on a new lighting system (wayyyyyyy more efficient than the raycasting one I posted a couple months ago).

Buuuuuuut, now I'm at a fork.  I need to choose between using a multiplicative algorithm for the lights/shadow blending and an additive method.  There is no performance difference, since the change is only in a couple fragment shaders.

Using a multiplicative method seems to make it appear as though the light is actually brightening the area around it, but the lights themselves are much less prominent (and this require some visual emphasis)

I have a system with 2 shadow casters (the two largest light sources) and 12 non shadow casing light sources.
This is what it looks like using a multiplicative algorithm:



This is what it looks like using an additive algorithm:


The big purple light moved a bit between the two, but that light follows the mouse. All the others are static.

I could go on for far too long about why I like one more than the other, but I want to hear what you think.

As far as 360-400fps for 14 lights goes in terms of performance, it's meh, but I'll optimize it later.

5

SFML projects / File Browser in SFML (Updated)

« on: February 08, 2017, 05:00:12 am »

**Update: Created a FileBrowser class to handle this, added the ability to differentiate between files and folders, and added a way to signal a file was selected**

I decided to try to bang out a file browser using SFML and TGUI.  It's not pretty, but I wasn't going for that. I just wanted functionality.

It uses C++17's filesystem header, under std::experimental::filesystem::v1.  I compiled it using Visual Studio 2015, so I can't say if it would work on anything else.

If nothing else, perhaps someone can use it to see how I worked my way around the file system.
In the image below, you can see the trace I printed to the console as I went around.  Stopped on a fellow SFML work, Cendric (not to promote or anything, would never do that).



Code: 
https://github.com/JayhawkZombie/SFMLFileBrowser/tree/master

If you feel like watching it work:


Edit: a more pretty version, embedded in our engine (still incomplete) 

6

SFML projects / Dynamic Lighting [UnNamed]

« on: January 06, 2017, 07:59:01 am »

I've written a small dynamic lighting system for use in our engine.  It only casts hard shadows ( ) but I can have as many light as we need and as many shadow casting polygons as needed.

The algorithm doesn't sort any edges, so the geometry can be dynamic. It just needs to know the starting and ending point for each edge.

The algorithm is additive, so it does a sort of ray casting (can increase/decrease the number of rays cast) and traces out its path, keeping track of the edge closest to it. Whenever it falls off an edge and reaches another one, it uses that info to construct the area to draw the illuminated texture onto.  It uses a fragment shader to build its own texture depending on the kind of light, so you could make the light look however.

It's still very much a work in progress, but I thought I'd see what you guys think.  Still need to work on the shadow blending, since a shadow will still partially show if another light is over it.


https://www.youtube.com/watch?v=o2lpwo10Bf8&feature=youtu.be

It's certainly nothing compared to LTBL/LTBL2, but given that this is also part of a college project, I want to try to write as much of it from scratch as I can. 
If for some reason you want to see the code, it's here: https://github.com/JayhawkZombie/RayCasting

7

SFML projects / SFEngine - Splash Screen

« on: September 11, 2016, 11:31:48 pm »

My team is working on an Engine for a large project, and while it's a ways from being done, our team wanted to give credit to all the other software we're using in our engine.
This is just a simple splash screen for now, but I thought I'd see what you guys thought.  It's simple enough to add more complex things here, like particle effects, other animations, etc, so throw your ideas out here!  If we put an idea you recommended into it, you'll obviously be credited.
We haven't put in a credits/names page, but will later.

8

SFML projects / SFInterface - Yet another GUI library

« on: July 24, 2016, 11:07:09 pm »

I see it's been done quite a few times already, but I've been working on a GUI library using SFML.
I've kept the github repo private so far until it's in a more stable state, but I wanted to post here and see what people here thought.

Current Features

• (Attempt) at a unified, default design.  More inspired by "modern" UIs
• Animations, though it's in progress.  Set times for animations and infinite-looping animations work.
• Custom callbacks
• Extendable elements
• Texturing
• Clipping. Nothing inside an element will render outside of its bounds

Working On

• Drop-down lists
• Sliders
• Multi-threaded implementation.  It "works", but it could be cleaner.
• This is mainly to prevent users from making the app appear unresponsive by doing heavy workloads in the same thread (no more "Not Responding" if they do a ton of work in the main thread)
• Custom shaders.  Sort of low on priority list
• Resource manager

Obviously plenty of stuff still needs to be done, like fully handling resize events.  Everything that is rendered will stretch, but the collision goes kinda wonky.
You can derive from any of the built-in elements, as long as you override the 'render' function.  This may become optional in the future.

All event handlers have default actions that always get called, then there are additional rebindable callbacks you can register for an event (but you certainly don't have to, you can choose to do nothing).
The caveat is that these have to accept certain parameters.  I may change this in the future if I find a good way to do it.

You can take focus of the UI, if you wanted the user to be forced to interact with something in order to continue.  You can release focus, too, as well you should.

I would consider this pre-alpha, but I wanted to get input from people about features/appearance.  I'm the kind of person that can be incredibly picky about a UI that I use.  Anything too flashy/distracting is a huge negative to me.  Ignore the bright red circles, that's playing with infinite-looping animations.

You can change the speed/duration of animations dynamically.  It's timed using high_resolution_clock. Currently this is done by telling each element how long it has been since they were last rendered, but it's up to the element to determine if it's been long enough to update its animation.  I plan on changing this so the element doesn't need to worry about that.

There's a managing "Controller" class that has access to everything in the BaseElement class, so many of these changes shouldn't be too hard to implement.

Example (because I'm still keeping the repo private until it's ready to be used by others):

auto checkbox = SFInterface::CheckBox::Create(); //Yes, inspired by one of the favorite libraries here
checkbox->setSize(sf::Vector2f(100, 50));
checkbox->setPosition(sf::Vector2f(10, 200));
checkbox->setTextSize(10);
....
controller.add(checkbox);
 

Elements have default text/color attributes, so you don't necessarily have to change them.

Here's a small screenshot of a few elements on the screen:
http://imgur.com/a/TJOt1

The default graphics are vector graphics, recomputed whenever you adjust the size, so they won't get fuzzy even if they're really large.  Curved items are in the works, but smaller items would require fewer computations to resize.
The fonts sometimes go kind of fuzzy, but I'm working on that.  I'll probably have to use another font.

Ultimately, the custom shaders would be easy to use, nothing needing to write one yourself.

So, some questions, maybe.
If you were to use it, what sorts of things would you like handled automatically and what things would you like to be able to handle on your own?
I know what I would do, but I'm the one making this.

Improvements you might suggest? Features you might suggest?

Note, though, I'm a sole programmer.  There's no large team working on this.  I also really only have a Windows machine currently to test it, so Linux support isn't planned until later.

9

General / Updating Only Portion of Rendering Region

« on: April 06, 2016, 04:46:09 pm »

Hello, All!

No bugs/major problems to report, but I'm curious as to how I'd accomplish a certain task.

I have a project in which an element on the screen is only rendered in a certain region of the screen, regardless of whether or not the element itself covers more than just that region (anything outside of the region isn't displayed).

It took a while to try to find out how to do this, but it works, and this is the code that I have to do it in the main rendering thread:

        sf::View ElementView;
        sf::FloatRect ElementRect;
        sf::FloatRect Panel;
        for (auto & element : m_elements)
        {              
                ElementRect = sf::FloatRect(element->getPosition().x, element->getPosition().y, element->getSize().x, element->getSize().y);
                Panel = sf::FloatRect(ElementRect.left / m_windowSize.x, ElementRect.top / m_windowSize.y, ElementRect.width / m_windowSize.x, ElementRect.height / m_windowSize.y);
                ElementView.reset(ElementRect);
                ElementView.setViewport(Panel);
                wnd->setView(ElementView);
                element->render(wnd, state);
        }
 

The renderWindow's view is then set back to cover the whole screen (or windowed size) and displayed.

This is an example of what it looks like:(I'm sorry, I don't know to properly use the image tags)


A couple questions I have about this:

• Is this what the people here would say is a good way to accomplish this clipping that I want?
          - If not, I'd love to hear suggestions! Any and all advice/feedback is appreciated!
• Is it safe to set the window view to just the view to only render in this element's rendering region, clear it, and then render, then reset the renderWindow's view back to normal after doing this and then displaying?  I seem to have a gap in my understanding of the API.

Any element may, without notice, update itself and need to be rendered again. Currently, the application does not render any object unless it absolutely has to. 
For instance, just sitting there with the mouse just sitting there (no animations or anything) will cause no rendering to be done - it will wait for an event (actually wait by sleeping the event thread).
However, if a single element is updated, then I don't see any reason to wake up my main render thread and waste CPU time by rendering everything over again.
I could very well just be over-complicating this (I have a horrible habit of doing that).

I apologize if this has been asked before, but it seems questions regarding clipping and redrawing aren't the easiest to find/find answers to.  I do know (some) raw OpenGL, but I love the usage of SFML and I really want to avoid jumping down into OpenGL (except shaders,  I love making/playing with shaders).

If my method of clipping isn't right or should be done in a different way, please feel free to say so.  I'm always learning, and I'd rather learn that I was doing it wrong and then learn how to do it right 

Thank you!

10

General / SFML with Visual Studio 2013 - Program Crash at texture load

« on: April 02, 2015, 10:26:01 pm »

Hi, all.
I can't seem to get SFML 2.2 to work in Visual Studio. I've gotten 2.1 to work, so I'm not sure what I'm doing incorrectly.
There seems to be an issue when I try to load a texture from a file.  I've made sure that the file is actually in the directory.
The console absolutely freaks out when the texture load function is called, and I get the usual "Your program has stopped working" error from Windows, which is useless because it gives no reasoning as to why.

The SFML sample of drawing a green circle works fine.

These are my Visual Studio settings:

C++/General
Additional Include Directories: C:\SFML\SFML-2.2-32\include
Linker/General
Additional Library Directories: C:\SFML\SFML-2.2-32\lib
Linker/Input
Additional Dependencies: sfml-graphics.lib
sfml-window.lib
sfml-system.lib
sfml-audio.lib
sfml-network.lib

I have copied all the DLL files to my project's directory.
I don't have any pre-processor settings set.

This is the code I'm using:

#include <iostream>

#include <SFML/System.hpp>
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>

int main()
{
   sf::RenderWindow window(sf::VideoMode(500, 500), "SFML works!");
   sf::CircleShape shape(100.f);
   shape.setFillColor(sf::Color::Green);

   sf::Sprite sprite;
   sf::Texture texture;
   

   //The program freaks out here
   //a bunch of incoherent stuff outputs from the console and the application freezes
   if (!texture.loadFromFile("sfml-logo-big.bmp"))
   {

   }

   while (window.isOpen())
   {
      sf::Event event;
      while (window.pollEvent(event))
      {
         if (event.type == sf::Event::Closed)
            window.close();
      }

      window.clear();
      window.draw(shape);
      window.display();
   }

   return 0;
}


The output from the console when it crashes is just thousands of random, incoherent characters - kind of like what you'd see if you tried to look an encrypted file.

Did I mess up setting this up?  I thought I set it up correctly, since the drawing of a green circle works fine.