Vanishing Circle Problem

[scross]

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)

[nulloid]

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?

[Laurent]

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.

[scross]

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

[nulloid]

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

No, I thought about something completely different. If you fail with your current plan, I will explain.

Thanks everyone for your quick responses btw Smile

You are welcome ^^,

[Laurent]

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

[scross]

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.

[Laurent]

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?

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).
It also allows more flexibility and optimizations on my side, like batching.

[scross]

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.

[Laurent]

Do you mean the CPU?

Oops, yes