Download Opengl Viewer |BEST|
Ellen Woolcock
I haven't tried building the library from source. From what I've seen, it doesn't appear that others are having the same issue installing through the repositories. I even found this Gentoo Forum post by someone who inadvertently was using the OpenGL viewer and was complaining about the old keybindings not working.
Thanks Extrude. Thinking long term, because when Apple drops some big change, within a year or two Windows and Linux do the same. I can see LL, viewer makers, and content makers grumbling loudly but eventually shifting over.
At least the Sansar distraction is out of the way, but we need something better than a drip, drip, drip of near-rumour from a few privileged third-party viewer developers. Apple have been deprecating OpenGL for years. It would have been reckless to jump straight on the Vulkan bandwagon in 2015, but Apple's deadline is the end of this year. They're telling everyone.
So how would this apply to Second Life? Would there be any benefit to running a translation layer for OpenGL to Vulkan? I was curious about this, and it just so happens that current open source Mesa drivers on Linux (for AMD and Intel graphics only) can use a relatively new feature called Zink to do just this. Zink is still experimental and in active development. I was able to run a Second Life viewer using Zink, but it's very sluggish and has artifacts. Perhaps this will change, but I'm hoping for a native Vulkan renderer in the viewer some day. Vulkan works on Windows the same way it does on Linux. As for Mac, the MoltenVK API should work with hardly any loss of performance.
Image: Second Life viewer running OpenGL to Vulkan at the driver level. Notice the odd looking eyes. Also, the mesh on the avatar will go to lower LODs very quickly for some reason, disintegrating at a much shorter distance than expected.
Additionally, the Lindens also seem insistent on supporting 16 year old hardware and are still doing opengl checks for below 3.0 in llgl.cpp. Even their hardware query for vram, opengl version, and device driver stuff is still handled like its 2002. Plus there are snippets of code for ATI compatibility floating around, its ludicrous their gpus haven't existed for 15 years. Frankly, if people are running 15 year old gpus, they likely are not the ones spending money on the game. Linden Labs needs to get a grip and up the min opengl spec to at least to 3.3 or 4.
A right-handed coordinate system always looks down the -Z axis. If +X goes right, and +Y goes up (which is how all of OpenGL works), and the view is aligned to the Z axis, then +Z must go towards the viewer. If the view was looking down the +Z axis, then the space would be left-handed.
Stereo viewing is accomplished by presenting a different image to the left and right eyes of the viewer. These images must be appropriate for the viewers relationship to the display they are looking at, much moreso than a mono 3D image. In addition the method used is tied closely to the display technology being used. Some graphics systems and display devices support stereo viewing in hardware and support features like left and right framebuffers in addition to the front and back buffers of conventional double buffered systems. Other systems support stereo correctly when two viewports are created in specific screen regions and specific video mode is used to send these to the screen. In conjunction with these modes a viewer often wears glasses either shuttered or polarized to select the displayed image appropriate to each eye. However even without these graphics features a developer can generate stereo views using features like color filtering where colored filters select an image based on red or blue filters and draw left and right eye images to red and blue framebuffer components for example, or even more simply just have multiple systems or graphics cards (or even a single card) generate two entirely separate video signals, for which a separate left and right eye image is drawn. The video is then sent to the appropriate eye either using a display employing polarizing filters or a head mounted display or some other custom display operating on similar principals.
From an OpenGL perspective, the requirements of stereo rendering are to use the appropriate setup to render to left and right eyes (be it color masks, separate contexts or different viewports) and then match the geometry of the OpenGL projection to the relationship of the viewer's left and right eyes with the display. The final OpenGL requirement is that the position of the eyes in the 'virtual' world must be given a pupil separation on the modelview stack, this separation would of course be a translation in eye space, but could be calculated in other equivalent ways.
It's the application's responsibility to ensure that the Projection and ModelView matrices are constructed to provide an image that keeps the viewer at an appropriate distance, with an appropriate field of view, and keeps the zNear and zFar clipping planes at an appropriate range. An application that displays molecules in micron scale, for example, would probably not want to place the viewer at a distance of 10 feet with a 60 degree field of view.
Eye Coordinates result from transforming Object Coordinates by the ModelView matrix. The ModelView matrix contains both modelling and viewing transformations that place the viewer at the origin with the view direction aligned with the negative Z axis.
You have to find a draw call that renders one of these billboard quads , but once you do you can look at the mesh viewer to see if the vertex shader output is correct and do a pixel history check to see what the pixel shader outputs
As you can see, due to perspective the lines seem to coincide at a far enough distance. This is exactly the effect perspective projection tries to mimic and it does so using a perspective projection matrix. The projection matrix maps a given frustum range to clip space, but also manipulates the w value of each vertex coordinate in such a way that the further away a vertex coordinate is from the viewer, the higher this w component becomes. Once the coordinates are transformed to clip space they are in the range -w to w (anything outside this range is clipped). OpenGL requires that the visible coordinates fall between the range -1.0 and 1.0 as the final vertex shader output, thus once the coordinates are in clip space, perspective division is applied to the clip space coordinates: \[ out = \beginpmatrix x /w \\ y / w \\ z / w \endpmatrix \] Each component of the vertex coordinate is divided by its w component giving smaller vertex coordinates the further away a vertex is from the viewer. This is another reason why the w component is important, since it helps us with perspective projection. The resulting coordinates are then in normalized device space. If you're interested to figure out how the orthographic and perspective projection matrices are actually calculated (and aren't too scared of the mathematics) I can recommend this excellent article by Songho.
For this, OCCT Viewer updates should be put into callback for Gtk::GLArea::signal_render() signal and disallow any implicit/explicit V3d_View::Redraw() in application code. Instead, any viewer modifications should request widget updates via Gtk::GLArea::queue_draw().
Initially I was optimistic about Gtk::GLArea and expected it to work naturally with other GTK widgets. Unfortunately, even a very basic sample (before embedding OCCT viewer) displayed artifacts on Xubuntu 18.04 within a virtual machine and software-emulated OpenGL implementation.
I'd like to transform a sequence of circular fisheye-images to cubic or spherical panorama images to be used in a panorama-viewer based on OpenGL. The viewer-part is nemas problemas but the transform from fisheye to panorama is not my usual cup of tea. I was kind of expecting a google would solve this, but so far I have come up with next to nothing. What would the preferred method be? OpenGL or pixelshaders?
Since you're going to have a real-time panorama viewer anyway, it seems to me you could configure your panorama viewer to view the fisheye images directly. There is no need to convert them to a cubemap or lat-long format first.
A panorama viewer works by drawing a mesh of some shape (e.g. a cube or sphere) around the camera, and setting up texture coordinates on the mesh such that the image gets wrapped around the mesh in the same mapping used to generate the original image. So viewing fisheye images with it is just a matter of coding up the right mapping. I would suggest building a reasonably tessellated hemisphere and mapping spherical coordinates on the hemisphere to polar coordinates around the center of the 2D fisheye image. No pixel shaders will be needed, just standard texture mapping.
df19127ead