Messages

1

Graphics / sf::RenderWindow::Clear() causing Unhandled exception

« on: June 08, 2010, 10:54:11 pm »

I'm using Linux Mint, which is basically the same as Ubuntu and I encountered this same problem, with all my SFML-based programs working fine until I recompiled them. It turns out the earlier version (1.5) had installed its libraries to /usr/lib, whereas version 1.6 had installed its libraries to /usr/local/lib. I assumed this meant that my app was being linked to the old libs (perhaps meaning the wrong dynamic libs are used), and the problem somehow stemmed from that. Anyway, switching to root and eliminating the version 1.5 libraries has solved the problem.

2

Audio / Problems with sf::Music

« on: May 01, 2010, 08:39:54 pm »

Yeah, I think it's an ubuntu audio problem. I had the same thing and the following command fixed it:

Code: [Select]

sudo apt-get purge bluez-alsa

(from http://ubuntuforums.org/showthread.php?t=1136720&page=2 )

3

Graphics / Vanishing Circle Problem

« on: May 01, 2010, 08:18:58 pm »

Driver calls were simply a lot more expensive than doing all this stuff on the GPU (after all, transforming a vertex is just a few additions and multiplies).

Do you mean the CPU?

It also allows more flexibility and optimizations on my side, like batching.

That sounds good.

4

Graphics / Vanishing Circle Problem

« on: May 01, 2010, 06:34:27 pm »

What is SFML 2 introducing/changing that should make this easier?

SFML gives less control to OpenGL on the rendering process:
- The objects transformations are done on the CPU
- The view (projection) is applied on the GPU, but can easily be done on the CPU

Ok, that sounds good Out of interest, what reasons did you have initially for wanting to do object transformations on the CPU in SFML 2, rather than on the GPU as you appear to do in previous versions?

Thanks.

5

Graphics / Vanishing Circle Problem

« on: April 30, 2010, 09:13:52 pm »

I thought about your problem a little, and I found another way, although I am not sure about how much wok would it cost. My idea is to draw exactly what will be on the screen. So do an intersection between the sun and the viewport, than between the earth and the viewport, etc., and draw the result. How about that?

I'm not sure exactly what you're suggesting...it might be what I'm talking about, which is explained in more detail below...

I don't know what you mean by 'true', but yes, you'd have to implement it on the CPU rather than the GPU. Are you expecting such a transition to be costly performance wise? (It's probably important to note that speed isn't hugely important in my case)

I mean that there's nothing we can do because everything is handled on the GPU. And you can't really implement it on the CPU, unless you change the whole rendering process of SFML.

However this might be easier in SFML 2. But I'm still not 100% sure that it would solve your problem, it could be trickier than just switching everything we can to double precision.

It's not really a matter of changing the rendering process, as layering double precision calculations on top to find out where the graphical objects should be. Once these calculations are done, we simply draw the circles to the correct positions on the screen. In other words all the rotations, zooming and translations are performed at double precision, so that virtually no error is accumulated during these operations.

In the initial code which demonstrated the problem, I was placing the moon circle at its true position and then using sf::View to translate and zoom it, so that it appears in the centre of the screen, and this is where the error accumulated. Once all the objects are in the right place on the screen, high precision isn't at all important (after all, the smallest value in single precision floating point is about 1.0E-38, which will always be far smaller than a pixel).

What is SFML 2 introducing/changing that should make this easier?

Thanks everyone for your quick responses btw

6

Graphics / Vanishing Circle Problem

« on: April 30, 2010, 08:49:24 pm »

What you don't seem to realize is that SFML doesn't do anything, views and transformations are (almost) entirely done on the GPU through OpenGL.

You can't write a true double precision view.

I don't know what you mean by 'true', but yes, you'd have to implement it on the CPU rather than the GPU. Are you expecting such a transition to be costly performance wise? (It's probably important to note that speed isn't hugely important in my case)

7

Graphics / Vanishing Circle Problem

« on: April 30, 2010, 08:13:35 pm »

OpenGL uses single precision, and it's not going to change. It would be useless to support double precision in SFML.

Yes, ok, OpenGL uses single precision and this won't change. However it is worth providing a double precision version of sf::View, since this would avoid introducing error when points are translated to the centre of the screen. Once  the shapes are translated and resized by the view, there is absolutely no need for double precision, but as you can see with my problem it is valuable up until that point.

Anyway, if you were to do this, it is obviously a very low priority thing
It's pretty easy to throw together a custom double precision view, which I am doing now.

8

Graphics / Vanishing Circle Problem

« on: April 30, 2010, 05:05:16 pm »

What I'm suggesting is that SFML (on the CPU) should use double precision, even though the GPU may use single precision (hopefully future GPUs would have good support for higher precision). My point is that virtually nothing is lost by this approach, whereas it would help avoid problems like the one mentioned above.

And, if I understand it correctly, the amount of conversion between CPU and GPU is the same when using single-precision and double-precision?

You won't have to do any extra conversions and the conversion time from double to float will be negligible in most cases (every floating point operation involves two conversions to and from the internal format anyway, regardless of precision).

9

Graphics / Vanishing Circle Problem

« on: April 30, 2010, 04:49:43 pm »

As a side note, the value I was using for the moon is incorrect, and the moon is in fact 1.737E6 metres (i.e. 1000 * my previous value )

10

Graphics / Vanishing Circle Problem

« on: April 30, 2010, 04:45:51 pm »

I still think speed is a major factor. What do you say?

On the GPU, yes, single precision will be faster, but on the CPU there won't be a difference. What I'm suggesting is that SFML (on the CPU) should use double precision, even though the GPU may use single precision (hopefully future GPUs would have good support for higher precision). My point is that virtually nothing is lost by this approach, whereas it would help avoid problems like the one mentioned above.

11

Graphics / Vanishing Circle Problem

« on: April 30, 2010, 04:00:30 pm »

On x86, which is the architecture most used (if you have an AMD or Intel processor, you're almost certainly on x86), all floating point operations are on an internal 80 bit value, which is larger than both single and double precision. So effectively both single precision (32 bits) and double precision (64 bits) numbers are converted to an 80 bit value, such that neither precision is faster than the other. Of course, if you're storing a large number of floating point values, doubles do have a space impact.

This is all summarised nicely here: http://stackoverflow.com/questions/417568/float-vs-double-performance

12

Graphics / Vanishing Circle Problem

« on: April 30, 2010, 01:49:56 pm »

Ok, I've realised that there is a very simple solution to this, and that is to translate the circle to the centre of the screen. This is basically what sf::View does, however it only uses single precision floating point numbers, so you have to replace this with a similar mechanism for higher precision numbers. In fact, is there any good reason for sf::View not using higher precision to translate the coordinates?

Indeed, why shouldn't all of SFML use higher precision floating point numbers? Of course it's understandable that the hardware and/or graphics libraries (OpenGL) may only be able to deal with single precision, but this may change in future. Quite usefully, the Vector2 class can be specified with a template parameter that allows the use of double precision components, but the view class is still limited to single precision.

Anyway, I've adapted the code quite simply to make it work as follows:

Code: [Select]

int main(){
sf::RenderWindow App(sf::VideoMode(1024, 768, 32), "2D Gravity Simulator");

double sunRadius = 6.955E8;
double earthRadius = 6.3781E6;
double moonRadius = 1.737E3;

double sunX = 0.0, sunY = 0.0;
double earthX = 1.49682955E11, earthY = 0.0;
double moonX = 1.50067354E11, moonY = 0.0;

sf::Vector2f sunHalfSize(sunRadius, sunRadius);
sf::Vector2f earthHalfSize(earthRadius, earthRadius);
sf::Vector2f moonHalfSize(moonRadius, moonRadius);

sf::Vector2f startPos(0.0, 0.0);
sf::View view(startPos, sunHalfSize);
    App.SetView(view);

    double pX = 0.0, pY = 0.0;

    while (App.IsOpened()){
    App.Clear();

sf::Event Event;
while (App.GetEvent(Event)){
            if(Event.Type == sf::Event::Closed){
App.Close();
}
if(App.GetInput().IsKeyDown(sf::Key::S)){
view.SetHalfSize(sunHalfSize);
pX = sunX;
pY = sunY;
}else if(App.GetInput().IsKeyDown(sf::Key::E)){
view.SetHalfSize(earthHalfSize);
pX = earthX;
pY = earthY;
}else if(App.GetInput().IsKeyDown(sf::Key::M)){
view.SetHalfSize(moonHalfSize);
pX = moonX;
pY = moonY;
}
}

App.Draw(sf::Shape::Circle(sunX - pX, sunY - pY, sunRadius, sf::Color(255.0, 0.0, 0.0)));
App.Draw(sf::Shape::Circle(earthX - pX, earthY - pY, earthRadius, sf::Color(0.0, 255.0, 0.0)));
App.Draw(sf::Shape::Circle(moonX - pX, moonY - pY, moonRadius, sf::Color(0.0, 0.0, 255.0)));
        App.Display();
    }

    return 0;
}

13

Graphics / Vanishing Circle Problem

« on: April 28, 2010, 01:51:56 pm »

This is not a math test, you have to provide code in a simplified example if you want real help.

The following code demonstrates the problem:

Code: [Select]

#include <SFML/Graphics.hpp>
int main(){
sf::RenderWindow App(sf::VideoMode(1024, 768, 32), "2D Gravity Simulator");

double sunRadius = 6.955E8;
double earthRadius = 6.3781E6;
double moonRadius = 1.737E3;

sf::Vector2f sunPos(0.0, 0.0);
sf::Vector2f earthPos(1.49682955E11, 0.0);
sf::Vector2f moonPos(1.50067354E11, 0.0);

sf::Vector2f sunHalfSize(sunRadius, sunRadius);
sf::Vector2f earthHalfSize(earthRadius, earthRadius);
sf::Vector2f moonHalfSize(moonRadius, moonRadius);

sf::View view(sunPos, sunHalfSize);
    App.SetView(view);

    while (App.IsOpened()){
    App.Clear();

sf::Event Event;
while (App.GetEvent(Event)){
            if(Event.Type == sf::Event::Closed){
App.Close();
}
if(App.GetInput().IsKeyDown(sf::Key::S)){
view.SetHalfSize(sunHalfSize);
view.SetCenter(sunPos);
}else if(App.GetInput().IsKeyDown(sf::Key::E)){
view.SetHalfSize(earthHalfSize);
view.SetCenter(earthPos);
}else if(App.GetInput().IsKeyDown(sf::Key::M)){
view.SetHalfSize(moonHalfSize);
view.SetCenter(moonPos);
}
}

App.Draw(sf::Shape::Circle(sunPos, sunRadius, sf::Color(255.0, 0.0, 0.0)));
App.Draw(sf::Shape::Circle(earthPos, earthRadius, sf::Color(0.0, 255.0, 0.0)));
App.Draw(sf::Shape::Circle(moonPos, moonRadius, sf::Color(0.0, 0.0, 255.0)));
        App.Display();
    }

    return 0;
}

You press 'S' to zoom in on the sun, 'E' to zoom in on the Earth and 'M' for the moon. You should notice that the sun and the earth appear correctly, while the moon does not appear at all. However, if you move the moon so that it is closer to the origin (the sun) then you will find it starts to appear correctly. You can also increase its size, which will make it be shown correctly.

I think the problem is your scale is messed up. If you are using 2D graphics to draw the sun and the moon you should scale down and round. There are only so many pixels on the screen no matter what the physics suggest. What you see with your eyes is very limited.

The problem doesn't have anything to do with pixels on the screen, if that's what you're saying, since the program zooms in to each of the circles. Rather, the problem has to do with how the circles are stored in OpenGL.

SFML, OpenGL and your graphics card use single precision floating point numbers. So both very big and very small numbers are likely to produce this kind of artifacts.

Ok, I wasn't aware of this, thank you. I've worked out what's going on: the problem is the addition of the small radius of the moon with the large distance between the sun and the moon. Single precision floating point can only deal with around 7 decimal places in base 10, whereas the difference between the values would be 8 decimal places, thus the value of the radius of the moon is simply truncated from the result. This means that all the points of the circle are drawn in the same place and hence no circle appears.

As for how to solve this, I may have to scale up the moon as I zoom in on it. Any other potential solutions?

14

Graphics / Vanishing Circle Problem

« on: April 27, 2010, 02:23:08 pm »

I have a problem in which I have 3 circles with radii of greatly varying magnitude, however the smallest of the circles does not appear, but it does flash occasionally. The context here is a gravity simulator, where the 3 circles represent the Sun, Earth and Moon and the values for the radii are therefore approximately 6.955E8, 6.3781E6 and 1.737E3 metres respectively. The moon is the circle which is not visible (yes, I'm at the correct zoom to see it) and if I make the radius of the moon 10* larger it appears as a rather skewed circle. The radius of the sun is therefore about 100,000 * the radius of the moon, and I would guess this is the source of problem. So I'm asking the question to verify if this is the case, and if so to ask why. It'd also be useful if you could suggest a way around the problem. Finally, since I'm likely to switch the graphical part of the simulator to use 3D (with Ogre3D) some time in the future, can I expect similar problems then?

As a side note, I'm obviously aware that it's certainly not possible to see the sun and the moon on the same image, since one is so much larger than the other. Indeed, it isn't even possible to see the sun and the earth together. However, I'd like the user to be able to zoom in to get an idea of the difference in magnitudes between the solar system bodies.