Thank you for the update Janus.
Are the missing libraries something I can go back to the people who modified 1.4.1 and enquire about? If you let me know a little more of exactly what I should ask for, I have no problem going back to them and asking.
Your friend's proposed home planetarium sounds intriguing! Will it use spherical mirror projection?
Mario
Spherical Mirror Projection?
@ImmersiveTheatres
Sadly, the missing libraries are a problem because there is no way to know which (version) ones are needed.
I run into this with source trees quite consistently.
Standard libraries are dynamic, but predictable as long as they remain clean.
Custom libraries are messy at best, and a disaster if mixed with standard libraries.
Include any library not a part of the standard library in the source tree, and reproduction gets easier.
I understand why some people like vcpkg or the linux equivalent, and those work as long you have no version dependencies.
Yet version dependencies are a fact of life when optimizing.
While I know it uses GLU, it also uses GLEW, I do not know their relationship at the moment of compile, or their context for display.
There is no predicting interdependancies of libraries outside of the source tree, which is why I always include them.
In this case, unless someone has a snap shot of the system, it is a game of 'whack a mole' finding the problem.
It will most likely take someone who knows a lot more than I do about opengl integrate it.
Janus.
Sadly, the missing libraries are a problem because there is no way to know which (version) ones are needed.
I run into this with source trees quite consistently.
Standard libraries are dynamic, but predictable as long as they remain clean.
Custom libraries are messy at best, and a disaster if mixed with standard libraries.
Include any library not a part of the standard library in the source tree, and reproduction gets easier.
I understand why some people like vcpkg or the linux equivalent, and those work as long you have no version dependencies.
Yet version dependencies are a fact of life when optimizing.
While I know it uses GLU, it also uses GLEW, I do not know their relationship at the moment of compile, or their context for display.
There is no predicting interdependancies of libraries outside of the source tree, which is why I always include them.
In this case, unless someone has a snap shot of the system, it is a game of 'whack a mole' finding the problem.
It will most likely take someone who knows a lot more than I do about opengl integrate it.
Janus.
-
onetwothree
- Site Admin
- Posts: 704
- Joined: 22.09.2018
- With us: 5 years 7 months
-
Anthony_B_Russo10
- Moderator
- Posts: 671
- Joined: 03.07.2018
- Age: 21
- With us: 5 years 10 months
- Location: Tallahassee, Florida, US
This is more for planetarium use.
Anthony B. Russo, I like Pluto. Mod of the Celestia subreddit: https://www.reddit.com/r/Celestiasoftware/
I have over 40 computers, trying to list them here would be a pain.
Responsible for the NEO catalog: https://celestia.space/forum/viewtopic.php?f=23&t=22203
And mod of the Discord server.
I have over 40 computers, trying to list them here would be a pain.
Responsible for the NEO catalog: https://celestia.space/forum/viewtopic.php?f=23&t=22203
And mod of the Discord server.
@Lendonqiwi
If I understand you correctly, you are asking about the use of spherical projection with a curved monitor.
If so, then the spherical projection will not help you.
In part this is because monitors mostly display a ribbon at the equator, whereas spherical projection includes the sky.
The issue is instead of just having edge distortion to deal with, you would also have top/bottom distortion as well.
Instead, what you need is an aberration correction, or in opengl's case, a decorrection.
If you want it in shorthand, it is a secant/chord VS arc problem.
You see the world from the inside of a sphere, but your monitor is flat.
This may make it clearer with a quick illustration, inspired by a drawing on wikipedia, Circular_segment.
This is not intended to be a scientific paper, it is written from the viewer standpoint for elucidation.
There is no point in burying people in math when a picture will achieve what most need, and the math remains if they want to know more.
Measures are from bridge of nose, ignoring elevation, to center of screen.
Wider monitors can be further away and still achieve the same viewing angles, which is the only measure here.
Warning: I am not an artist.
Warning: I am not a real OpenGL programmer.
We start with a circle having a radius of one to the edges of the monitor, that makes the math less messy.
It also simplifies the illustration
At 24 degrees, the arc and the screen are both 0.42 of the viewing distance.
In this narrow view, there is barely any discernible difference between the arc you see, and the flat of the screen.
At 90 Degrees, the screen is 1.41 times your viewing distance, while your sight arc is 1.57, which shows the problem.
This means the pixels now have discernible distortion. The edge more so than the middle where they are nearly the same.
It is also a common gaming view port angle, especially with wide monitors.
It also places the center of a flat monitor 0.29 of the viewing distance closer than the edges.
At 120 Degrees, your screen is now 1.73 times your viewing distance wide, but your viewing arc is 2.09 times.
Edge pixels have large distortion, which slowly fades out toward center.
The center is now 0.50 viewing distance closer, which accentuates the problem.
This is a diopter(sp?), or halving of the distance, a large change in focus depth, tiring the eyes if done continuously.
The level of distortion of edge pixels is now huge.
Simply moving from 120 to 119 degrees illustrates the problem.
The Arc width changes >1.6 times as much as the chord, which is your monitor.{0.00879 vs 0.01476)
The ratio is from the difference between the arc and chord distances per degree at that angle.
This ratio of distance per degree between arc and chord fades to one at the center, then rises again once past.
You can goto Circle Segment Calculator and see for yourself how fast things change.
A curved monitor moves the observer forward, reducing apparent R by reducing the secant, or distance between the sight arc and and viewing chord.
The advantage for gamers is it moves the edges of the screen toward the edge of vision without extreme distortion.
The center of our vision is detail oriented, whereas our peripheral vision is more motion oriented.
This allows natural reflexes to work as intended, triggering from visual motion.
In an FPS, sensing the motion even without knowing/recognizing its source, is an advantage.
Hence the use of curved monitors in high end gaming, and some types of simulators.
I hope I haven't wandered to far, but I have been asked this sort of question a lot.
I wanted to put it all into words to help me clarify it in advance of the next time, and I hope it helps someone here.
Engineers also seem to like the curved monitors while using cad programs, so it not just gamers.
Janus.
If I understand you correctly, you are asking about the use of spherical projection with a curved monitor.
If so, then the spherical projection will not help you.
In part this is because monitors mostly display a ribbon at the equator, whereas spherical projection includes the sky.
The issue is instead of just having edge distortion to deal with, you would also have top/bottom distortion as well.
Instead, what you need is an aberration correction, or in opengl's case, a decorrection.
If you want it in shorthand, it is a secant/chord VS arc problem.
You see the world from the inside of a sphere, but your monitor is flat.
This may make it clearer with a quick illustration, inspired by a drawing on wikipedia, Circular_segment.
This is not intended to be a scientific paper, it is written from the viewer standpoint for elucidation.
There is no point in burying people in math when a picture will achieve what most need, and the math remains if they want to know more.
Measures are from bridge of nose, ignoring elevation, to center of screen.
Wider monitors can be further away and still achieve the same viewing angles, which is the only measure here.
Warning: I am not an artist.
Warning: I am not a real OpenGL programmer.
We start with a circle having a radius of one to the edges of the monitor, that makes the math less messy.
It also simplifies the illustration
At 24 degrees, the arc and the screen are both 0.42 of the viewing distance.
In this narrow view, there is barely any discernible difference between the arc you see, and the flat of the screen.
At 90 Degrees, the screen is 1.41 times your viewing distance, while your sight arc is 1.57, which shows the problem.
This means the pixels now have discernible distortion. The edge more so than the middle where they are nearly the same.
It is also a common gaming view port angle, especially with wide monitors.
It also places the center of a flat monitor 0.29 of the viewing distance closer than the edges.
At 120 Degrees, your screen is now 1.73 times your viewing distance wide, but your viewing arc is 2.09 times.
Edge pixels have large distortion, which slowly fades out toward center.
The center is now 0.50 viewing distance closer, which accentuates the problem.
This is a diopter(sp?), or halving of the distance, a large change in focus depth, tiring the eyes if done continuously.
The level of distortion of edge pixels is now huge.
Simply moving from 120 to 119 degrees illustrates the problem.
The Arc width changes >1.6 times as much as the chord, which is your monitor.{0.00879 vs 0.01476)
The ratio is from the difference between the arc and chord distances per degree at that angle.
This ratio of distance per degree between arc and chord fades to one at the center, then rises again once past.
You can goto Circle Segment Calculator and see for yourself how fast things change.
A curved monitor moves the observer forward, reducing apparent R by reducing the secant, or distance between the sight arc and and viewing chord.
The advantage for gamers is it moves the edges of the screen toward the edge of vision without extreme distortion.
The center of our vision is detail oriented, whereas our peripheral vision is more motion oriented.
This allows natural reflexes to work as intended, triggering from visual motion.
In an FPS, sensing the motion even without knowing/recognizing its source, is an advantage.
Hence the use of curved monitors in high end gaming, and some types of simulators.
I hope I haven't wandered to far, but I have been asked this sort of question a lot.
I wanted to put it all into words to help me clarify it in advance of the next time, and I hope it helps someone here.
Engineers also seem to like the curved monitors while using cad programs, so it not just gamers.
Janus.
onetwothree wrote:Just a few minutes ago @markerz merged his branch to master. Now we have support for fish eye projection and some other distortions. Some work is still to be done but the most important part is finished.
I have the pre-release 1.7 version under Win 10.
How can I try the fish eye projection and the distortions?
-
onetwothree
- Site Admin
- Posts: 704
- Joined: 22.09.2018
- With us: 5 years 7 months
john71 wrote:How can I try the fish eye projection and the distortions?
Update your celestia.cfg with the following:
Code: Select all
ViewportEffect "warpmesh"
WarpMeshFile "warp.map"
ProjectionMode "fisheye"warp.map can be taken from https://build.opensuse.org/source/home:munix9:uns ... cfd0b982b80eb4f4424d1f67c3e72c
it should be put into warp sub-directory of you celestia installation.