Discussion:
Screen warping / edge blending for projectors
(too old to reply)
Viktor Radnai
2016-11-23 04:20:55 UTC
Permalink
Hi all,

I wrote a proof of concept implementation for screen warping in Flightgear
(largely based on the spherical display code) and wrote an utility for
producing calibration data for it. The details for the Flightgear bits are
here, along with a couple of pics showing it in action:

https://forum.flightgear.org/viewtopic.php?f=6&t=31058

The calibration utility is here:
https://github.com/viktorradnai/screenwarp

The whole thing is a quick hack that I threw together in a day or two. It
could do with a lot of improvements but it works if you are patient enough
tweaking the photo of the test pattern.

I'd like to see this added to Flightgear. The patch is in the forum post
above, it works with 2016.4.1. There are probably better ways to store and
load the calibration data (.ac file maybe?) but I'm an OSG newbie and I
wasn't taking any chances. Improvement suggestions are welcome.

So far the only limitation is that only one warped image is supported per
screen. This is because the code uses the viewport width and height to
scale the texture rather than the camera width and height. So if there are
multiple warps configured they will be stacked on top of each other I
think, rather than being placed where the config.xml says.

Let me know what I need to do to get this merged.

Cheers,
Vik
--
My other sig is hilarious
James Turner
2016-11-23 08:19:56 UTC
Permalink
Post by Viktor Radnai
https://forum.flightgear.org/viewtopic.php?f=6&t=31058
https://github.com/viktorradnai/screenwarp
The whole thing is a quick hack that I threw together in a day or two. It could do with a lot of improvements but it works if you are patient enough tweaking the photo of the test pattern.
I'd like to see this added to Flightgear. The patch is in the forum post above, it works with 2016.4.1. There are probably better ways to store and load the calibration data (.ac file maybe?) but I'm an OSG newbie and I wasn't taking any chances. Improvement suggestions are welcome.
So far the only limitation is that only one warped image is supported per screen. This is because the code uses the viewport width and height to scale the texture rather than the camera width and height. So if there are multiple warps configured they will be stacked on top of each other I think, rather than being placed where the config.xml says.
Let me know what I need to do to get this merged.
Hi Viktor, this looks a pretty nice addition.

As you said, it would be good to change a couple of things:

- loading a mesh format, probably an .obj or .ac, as the distortion mesh
- making it work per-camera

However, I’m not sure if the existing spherical distortion also has the same second limitation?

For the first item, writing a simple .ac or .obj from a Python script should be trivial. You can then load this into an osg::Geometry using osgDB::ReadFile and that will give you an osg::Geometry.

I think OBJ may be a better format actually since it supports multiple tex coords per vertex I think. If you need help with doing that just ask.

Are you happy to add the Python script to flightgear’s tools/ dir, or prefer to keep it on GitHub?

Kind regards,
James


------------------------------------------------------------------------------
Viktor Radnai
2016-11-23 12:07:50 UTC
Permalink
Hi James,

I'll look into using the .obj format. I've only briefly looked at .ac. I'll
try to get the conversion of the Python script and the patch done by the
end of the week. Regarding the merits of the two formats, I expect that at
some point the warp and intensity grids may diverge as the calibration
utility is being developed further. I'd like to look at automatic
calibration of intensity and edge overlaps as the next step.

I'd like to make the warping work per-camera, with multiple warped images
on a single screen, however the spherical screen should have the same
limitation. Both are called from the same method
(CameraGroup::buildDistortionCamera) that gets the width and height from
the viewport object. That should be the place to fix it as well.

Not sure what to do with the Python script -- I'd like to keep it where it
gets the most love. The calibration method isn't specific to Flightgear or
even to OSG, and if the output is an industry standard 3D object then there
is no reason why this couldn't be added to other simulators, games, etc.
But I wasn't planning on going around promoting it outside the Flightgear
community apart from making the OSG devs aware of it. Maybe they'll package
the warping code into a canned OSG solution like the SphericalDisplay /
PanoramicSphericalDisplay classes.

Can you think of any drawbacks for keeping it in a separate repo for the
moment?

Cheers,
Vik
Post by Viktor Radnai
I wrote a proof of concept implementation for screen warping in
Flightgear (largely based on the spherical display code) and wrote an
utility for producing calibration data for it. The details for the
Post by Viktor Radnai
https://forum.flightgear.org/viewtopic.php?f=6&t=31058
https://github.com/viktorradnai/screenwarp
The whole thing is a quick hack that I threw together in a day or two.
It could do with a lot of improvements but it works if you are patient
enough tweaking the photo of the test pattern.
Post by Viktor Radnai
I'd like to see this added to Flightgear. The patch is in the forum post
above, it works with 2016.4.1. There are probably better ways to store and
load the calibration data (.ac file maybe?) but I'm an OSG newbie and I
wasn't taking any chances. Improvement suggestions are welcome.
Post by Viktor Radnai
So far the only limitation is that only one warped image is supported
per screen. This is because the code uses the viewport width and height to
scale the texture rather than the camera width and height. So if there are
multiple warps configured they will be stacked on top of each other I
think, rather than being placed where the config.xml says.
Post by Viktor Radnai
Let me know what I need to do to get this merged.
Hi Viktor, this looks a pretty nice addition.
- loading a mesh format, probably an .obj or .ac, as the distortion mesh
- making it work per-camera
However, I’m not sure if the existing spherical distortion also has the
same second limitation?
For the first item, writing a simple .ac or .obj from a Python script
should be trivial. You can then load this into an osg::Geometry using
osgDB::ReadFile and that will give you an osg::Geometry.
I think OBJ may be a better format actually since it supports multiple tex
coords per vertex I think. If you need help with doing that just ask.
Are you happy to add the Python script to flightgear’s tools/ dir, or
prefer to keep it on GitHub?
Kind regards,
James
------------------------------------------------------------
------------------
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
My other sig is hilarious
James Turner
2016-11-23 13:41:48 UTC
Permalink
I'll look into using the .obj format. I've only briefly looked at .ac. I'll try to get the conversion of the Python script and the patch done by the end of the week. Regarding the merits of the two formats, I expect that at some point the warp and intensity grids may diverge as the calibration utility is being developed further. I'd like to look at automatic calibration of intensity and edge overlaps as the next step.
I’d suggest OBJ, it is likely slightly less work to generate that AC
I'd like to make the warping work per-camera, with multiple warped images on a single screen, however the spherical screen should have the same limitation. Both are called from the same method (CameraGroup::buildDistortionCamera) that gets the width and height from the viewport object. That should be the place to fix it as well.
I can check, I suspect this is something I could fix, although I never touched this code before. But I would hope the camera viewport is available nearby and hence could be passed into buildDistortionCamera. Torsten, Stuart, any ideas?
Not sure what to do with the Python script -- I'd like to keep it where it gets the most love. The calibration method isn't specific to Flightgear or even to OSG, and if the output is an industry standard 3D object then there is no reason why this couldn't be added to other simulators, games, etc. But I wasn't planning on going around promoting it outside the Flightgear community apart from making the OSG devs aware of it. Maybe they'll package the warping code into a canned OSG solution like the SphericalDisplay / PanoramicSphericalDisplay classes.
Can you think of any drawbacks for keeping it in a separate repo for the moment?
I’d say keep it separate for now if it’s generic, and we can document a link to GitHub and if we choose, take a current copy when building a release version. No big deal.

Kind regards,
James


------------------------------------------------------------------------------
Thorsten Renk
2016-11-23 15:57:08 UTC
Permalink
Aircraft maintainers (especially JSBSim) - please read this!

(Partially a recap from other discussions)

While updating the blackout/redout simulation to something more
sophisticated, we noted several oddities of how accelerations are
referenced aircraft-side.

Problem 1:

/accelerations/pilot-gdamped

This property was previously only active if the user had opted to run
blackout/redout or head shake simulation. If used to drive an
accelerometer/fuel flow/... this would not have worked if the user did not
simulate blackout.

-> We are now updating it unconditionally which should restore
accelerometers etc. to always working condition

Problem 2:

/accelerations/pilot-g

This is a YaSim-generated property and it had a constant value for JSBSim
aircraft before our recent change, so using it in JSBSim never worked.

Again effects, accelerometers and fuel simulations of JSBSim craft using
it naively were broken up to now. Forensics on a couple of JSBSim aircraft
referencing it shows that some authors have been aware of this and have
hacked around it by writing it from the JSBSim systms section, other's
have conditionals in Nasal script on whether it exists,....

-> We are now updating it also unconditionally. What we don't know is
whether actually updating this property interferes with some of the hacks
that have been used.

My strong recommendation is that JSBSim aircraft reference
/fdm/jsbsim/accelerations/* for their needs as to my knowledge we do not
officially maintain a common set of acceleration-related properties and I
consider updating the property via property rules not a clean way to solve
the problem (we do hope it's the most likely thing to restore
functionality to everything, but given the mixture of broken functions and
hacks we found before the recent change, there is no obvious 'best way'
forward).

If you're using the property in a JSBSim aircraft, please check that
everything still works as intended and consider simply not using it in the
future.

Problem 3:

The blackout/redout was explicitly considering YaSim and JSBSim, but UIUC
didn't seem to feature anywhere. I don't know if UIUC craft use this at
all or what the status is, but since Edward is a fan of them - can you
give it a quick check what happens there?

* Thorsten

------------------------------------------------------------------------------
Viktor Radnai
2016-11-26 11:53:15 UTC
Permalink
Hi James,

I've been busy improving the image capture and processing part so I didn't
get around to doing this yet. If you have the cycles to spare, you are most
welcome to jump in. If you could either update the patch to use an .obj
file and / or modify screenwarp.py to generate it, that would be very
helpful. Otherwise I think I'll eventually get to revisit this in a few
days.

My original submission had a bug where the texture x and y coordinates were
swapped (both in the screenwarp output, and in the patch, reversing the
effect). This is now fixed and the updated patch is here:
https://github.com/viktorradnai/screenwarp/blob/master/flightgear/screenwarp.patch

I've also added a new script (autocapture.py) that automates the capture of
the test images using the IP Webcam app on an Android smartphone to take
photos. Now I'm trying to work out overlap detection and the masking out of
unusable screen areas (eg. fouled corners).

Cheers,
Vik
Post by Viktor Radnai
I'll look into using the .obj format. I've only briefly looked at .ac.
I'll try to get the conversion of the Python script and the patch done by
the end of the week. Regarding the merits of the two formats, I expect that
at some point the warp and intensity grids may diverge as the calibration
utility is being developed further. I'd like to look at automatic
calibration of intensity and edge overlaps as the next step.
I’d suggest OBJ, it is likely slightly less work to generate that AC
Post by Viktor Radnai
I'd like to make the warping work per-camera, with multiple warped
images on a single screen, however the spherical screen should have the
same limitation. Both are called from the same method (CameraGroup::buildDistortionCamera)
that gets the width and height from the viewport object. That should be the
place to fix it as well.
I can check, I suspect this is something I could fix, although I never
touched this code before. But I would hope the camera viewport is available
nearby and hence could be passed into buildDistortionCamera. Torsten,
Stuart, any ideas?
Post by Viktor Radnai
Not sure what to do with the Python script -- I'd like to keep it where
it gets the most love. The calibration method isn't specific to Flightgear
or even to OSG, and if the output is an industry standard 3D object then
there is no reason why this couldn't be added to other simulators, games,
etc. But I wasn't planning on going around promoting it outside the
Flightgear community apart from making the OSG devs aware of it. Maybe
they'll package the warping code into a canned OSG solution like the
SphericalDisplay / PanoramicSphericalDisplay classes.
Post by Viktor Radnai
Can you think of any drawbacks for keeping it in a separate repo for the
moment?
I’d say keep it separate for now if it’s generic, and we can document a
link to GitHub and if we choose, take a current copy when building a
release version. No big deal.
Kind regards,
James
------------------------------------------------------------
------------------
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
My other sig is hilarious
Viktor Radnai
2017-05-31 23:32:50 UTC
Permalink
Hi all,

I have made improvements to the screen warping process and as a result I
got a warped and edge-blended cylindrical display mostly set up. A demo is
here:
and the code and config
is here: https://github.com/viktorradnai/screenwarp/tree/master/flightgear.
Documentation is coming :D

I have an updated patch for FightGear but I still haven't converted it to
use .obj or .ac files as we discussed several months ago. I'm looking at
converting it now, but it seems that by using either format the result
wouldn't be the same as how it's done now.

I'm a complete n00b when it comes to 3d graphics so please correct me if
I'm wrong with any of this. It seems to me that texture intensity is
implemented using colours eg. colors->push_back(osg::Vec4(i, i, i, i))
where "i" is the intensity value. In my patch (which I based on the
existing spherical display implementation) the colours are applied to the
vertices not the surfaces. This will result in the desired smooth intensity
transition but this does not look like something either the .ac or the .obj
format would support. These formats implement colours through materials (so
I would need to create a separate material for each intensity level I'd
like to use) and the materials apply to the entire surface rather than a
single vertex.

I haven't tried to convert a warp file yet, I wanted to get some help and
clarification before I would set out to do the conversion. So please let me
know if I understand this right and whether there is a way to solve this
issue.

Also there are two texture coordinate arrays (texcoord0 and texcoord1)
which are loaded up with identical data. What are those for?

BTW, if anyone would like to step in and improve either the patch or
anything else, your contributions would be most welcome.

Thanks in advance.

Cheers,
Vik
Post by Viktor Radnai
Hi James,
I've been busy improving the image capture and processing part so I didn't
get around to doing this yet. If you have the cycles to spare, you are most
welcome to jump in. If you could either update the patch to use an .obj
file and / or modify screenwarp.py to generate it, that would be very
helpful. Otherwise I think I'll eventually get to revisit this in a few
days.
My original submission had a bug where the texture x and y coordinates
were swapped (both in the screenwarp output, and in the patch, reversing
https://github.com/viktorradnai/screenwarp/blob/
master/flightgear/screenwarp.patch
I've also added a new script (autocapture.py) that automates the capture
of the test images using the IP Webcam app on an Android smartphone to take
photos. Now I'm trying to work out overlap detection and the masking out of
unusable screen areas (eg. fouled corners).
Cheers,
Vik
Post by Viktor Radnai
I'll look into using the .obj format. I've only briefly looked at .ac.
I'll try to get the conversion of the Python script and the patch done by
the end of the week. Regarding the merits of the two formats, I expect that
at some point the warp and intensity grids may diverge as the calibration
utility is being developed further. I'd like to look at automatic
calibration of intensity and edge overlaps as the next step.
I’d suggest OBJ, it is likely slightly less work to generate that AC
Post by Viktor Radnai
I'd like to make the warping work per-camera, with multiple warped
images on a single screen, however the spherical screen should have the
same limitation. Both are called from the same method
(CameraGroup::buildDistortionCamera) that gets the width and height from
the viewport object. That should be the place to fix it as well.
I can check, I suspect this is something I could fix, although I never
touched this code before. But I would hope the camera viewport is available
nearby and hence could be passed into buildDistortionCamera. Torsten,
Stuart, any ideas?
Post by Viktor Radnai
Not sure what to do with the Python script -- I'd like to keep it where
it gets the most love. The calibration method isn't specific to Flightgear
or even to OSG, and if the output is an industry standard 3D object then
there is no reason why this couldn't be added to other simulators, games,
etc. But I wasn't planning on going around promoting it outside the
Flightgear community apart from making the OSG devs aware of it. Maybe
they'll package the warping code into a canned OSG solution like the
SphericalDisplay / PanoramicSphericalDisplay classes.
Post by Viktor Radnai
Can you think of any drawbacks for keeping it in a separate repo for
the moment?
I’d say keep it separate for now if it’s generic, and we can document a
link to GitHub and if we choose, take a current copy when building a
release version. No big deal.
Kind regards,
James
------------------------------------------------------------
------------------
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
My other sig is hilarious
--
My other sig is hilarious
Erik Hofman
2017-06-01 07:00:57 UTC
Permalink
Post by Viktor Radnai
Hi all,
I have made improvements to the screen warping process and as a result I
got a warped and edge-blended cylindrical display mostly set up. A demo
is here: http://youtu.be/h4afj8YJTMU and the code and
https://github.com/viktorradnai/screenwarp/tree/master/flightgear.
Documentation is coming :D
Good work.
Post by Viktor Radnai
I have an updated patch for FightGear but I still haven't converted it
to use .obj or .ac files as we discussed several months ago. I'm looking
at converting it now, but it seems that by using either format the
result wouldn't be the same as how it's done now.
A quick search for this problem shows two options:

1. .obj files can in fact handle per vertex colors but I'm not sure if
OpenSceneGraph supports this:

https://gamedev.stackexchange.com/questions/21303/how-can-i-include-vertex-color-information-in-obj-files

2. Apparently the .ply format, which is supported by OpenSceneGraphs,
supports this

Erik
--
http://www.adalin.com - High performance virtual reality audio software.
Emilian Huminiuc
2017-06-01 07:05:12 UTC
Permalink
Post by Erik Hofman
Post by Viktor Radnai
Hi all,
I have made improvements to the screen warping process and as a result I
got a warped and edge-blended cylindrical display mostly set up. A demo
is here: http://youtu.be/h4afj8YJTMU and the code and
https://github.com/viktorradnai/screenwarp/tree/master/flightgear.
Documentation is coming :D
Good work.
Post by Viktor Radnai
I have an updated patch for FightGear but I still haven't converted it
to use .obj or .ac files as we discussed several months ago. I'm looking
at converting it now, but it seems that by using either format the
result wouldn't be the same as how it's done now.
1. .obj files can in fact handle per vertex colors but I'm not sure if
https://gamedev.stackexchange.com/questions/21303/how-can-i-include-vertex-c
olor-information-in-obj-files
2. Apparently the .ply format, which is supported by OpenSceneGraphs,
supports this
Erik
OSG supports the .obj format pretty well, it's Flightgear's effect system that
doesn't play well with them (it in fact assumes .ac format)

Regards,
Emilian
Erik Hofman
2017-06-01 07:07:46 UTC
Permalink
Post by Emilian Huminiuc
OSG supports the .obj format pretty well, it's Flightgear's effect system that
doesn't play well with them (it in fact assumes .ac format)
That would be a pity.

Erik
--
http://www.adalin.com - High performance virtual reality audio software.
Viktor Radnai
2017-06-01 08:21:48 UTC
Permalink
Post by Erik Hofman
Post by Emilian Huminiuc
OSG supports the .obj format pretty well, it's Flightgear's effect system that
doesn't play well with them (it in fact assumes .ac format)
That would be a pity.
That might not be as much of a problem as the glue code will need to be
written and it's really only used to create a single, standalone object
then render a texture on it.

But I'm wondering if there is an advantage in using a format that is poorly
supported by Flightgear and one the FlightGear community is unfamiliar
with? What do you guys suggest I do with it? I'm not a huge fan of
inventing my own "standards" but this code is already written.

Cheers,
Vik
Viktor Radnai
2017-06-04 23:22:01 UTC
Permalink
Hi all,

It seems that the ply format can do everything, but I'm new to OSG and
can't work out how to add the loaded object to the camera. The best I
managed so far is to get a single pixel of the texture mapped to the entire
screen object... Could someone please help me out with this?

The original solution created a geometry object, pushed some vertex,
texture and colour coordinates to it, then created the object itself from
triangles. Then it added the geometry object to a geode and applied the
texture containing the scene to the geode. It then added the geode to a
camera.

The code I have so far loads a node object, scales it using a matrix
transformation, applies the texture containing the scene to the matrix
transformation and then adds it to the camera.

Cheers,
Vik
Post by Viktor Radnai
Post by Erik Hofman
Post by Emilian Huminiuc
OSG supports the .obj format pretty well, it's Flightgear's effect system that
doesn't play well with them (it in fact assumes .ac format)
That would be a pity.
That might not be as much of a problem as the glue code will need to be
written and it's really only used to create a single, standalone object
then render a texture on it.
But I'm wondering if there is an advantage in using a format that is
poorly supported by Flightgear and one the FlightGear community is
unfamiliar with? What do you guys suggest I do with it? I'm not a huge fan
of inventing my own "standards" but this code is already written.
Cheers,
Vik
--
My other sig is hilarious
Viktor Radnai
2017-06-07 10:09:37 UTC
Permalink
Hi all,

Just a reminder, I'm still stuck with this and would appreciate some
guidance from someone who understands OSG.

Thanks in advance.

Cheers,
Vik
Post by Viktor Radnai
Hi all,
It seems that the ply format can do everything, but I'm new to OSG and
can't work out how to add the loaded object to the camera. The best I
managed so far is to get a single pixel of the texture mapped to the entire
screen object... Could someone please help me out with this?
The original solution created a geometry object, pushed some vertex,
texture and colour coordinates to it, then created the object itself from
triangles. Then it added the geometry object to a geode and applied the
texture containing the scene to the geode. It then added the geode to a
camera.
The code I have so far loads a node object, scales it using a matrix
transformation, applies the texture containing the scene to the matrix
transformation and then adds it to the camera.
Cheers,
Vik
Post by Viktor Radnai
Post by Erik Hofman
Post by Emilian Huminiuc
OSG supports the .obj format pretty well, it's Flightgear's effect system that
doesn't play well with them (it in fact assumes .ac format)
That would be a pity.
That might not be as much of a problem as the glue code will need to be
written and it's really only used to create a single, standalone object
then render a texture on it.
But I'm wondering if there is an advantage in using a format that is
poorly supported by Flightgear and one the FlightGear community is
unfamiliar with? What do you guys suggest I do with it? I'm not a huge fan
of inventing my own "standards" but this code is already written.
Cheers,
Vik
--
My other sig is hilarious
--
My other sig is hilarious
James Turner
2017-06-07 10:11:07 UTC
Permalink
Just a reminder, I'm still stuck with this and would appreciate some guidance from someone who understands OSG.
I can probably help, but I’m rather overloaded at the moment. Can you point me to your current code?

Kind regards,
James
Viktor Radnai
2017-06-07 11:57:21 UTC
Permalink
Hi James,

Thanks for this. I've pushed two commits to my fork of the 2017.2 release
branch here:
https://sourceforge.net/u/efti/flightgear-flightgear/ci/release/2017.2/~/tree/

The first one is my working "stable-ish" version using my own 'warp' file
format documented here:
https://github.com/viktorradnai/screenwarp/#warp-file-format
The second commit is the mess I've created while trying to add support to a
"warpscreen" node that will load the model (with a view of possibly
replacing all of the panoramic-spherical code with loaded models, including
the shape generated by createPanoramicSphericalDisplayDistortionMesh and of
course createCustomDistortionMesh which is my code). The interesting (an
problematic) bits are in buildDistortionCamera2.

Let me know if you would like to run this, rather than just looking. I'll
need to add a config file, a warp file and a ply file somewhere for you to
download.

Cheers,
Vik
Post by Viktor Radnai
Just a reminder, I'm still stuck with this and would appreciate some
guidance from someone who understands OSG.
I can probably help, but I’m rather overloaded at the moment. Can you
point me to your current code?
Kind regards,
James
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
My other sig is hilarious
Viktor Radnai
2017-06-28 00:52:20 UTC
Permalink
After spending some time on this, I see no evidence that OSG actually
supports reading texture coordinates from PLY files :( More precisely I
don't see any evidence that this submission has even made it into their git
repo. let alone a release:
https://www.mail-archive.com/osg-***@lists.openscenegraph.org/msg10293.html

For this reason I will stop working on trying to use one of the common 3D
formats unless someone can suggest one that supports x, y, z, u, v and
intensity coordinates for each vertex and actually works correctly with
OSG. All the code I used to generate the cylindrical projection can be
found in https://github.com/viktorradnai/screenwarp/
<https://github.com/viktorradnai/screenwarp/#warp-file-format> including
the patch for FlightGear, various ways of generating Warp files and a
converter to the PLY format. I'd love to get my patch into FlightGear,
although I understand that you might not want this until a proper 3D format
is used. If you are interested in merging this. let me know and I'll raise
a merge request.

Cheers,
Vik
Post by Viktor Radnai
Hi James,
Thanks for this. I've pushed two commits to my fork of the 2017.2 release
branch here: https://sourceforge.net/u/efti/flightgear-flightgear/ci/
release/2017.2/~/tree/
The first one is my working "stable-ish" version using my own 'warp' file
format documented here: https://github.com/viktorradnai/screenwarp/#warp-
file-format
The second commit is the mess I've created while trying to add support to
a "warpscreen" node that will load the model (with a view of possibly
replacing all of the panoramic-spherical code with loaded models, including
the shape generated by createPanoramicSphericalDisplayDistortionMesh and
of course createCustomDistortionMesh which is my code). The interesting (an
problematic) bits are in buildDistortionCamera2.
Let me know if you would like to run this, rather than just looking. I'll
need to add a config file, a warp file and a ply file somewhere for you to
download.
Cheers,
Vik
Post by Viktor Radnai
Just a reminder, I'm still stuck with this and would appreciate some
guidance from someone who understands OSG.
I can probably help, but I’m rather overloaded at the moment. Can you
point me to your current code?
Kind regards,
James
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
My other sig is hilarious
--
My other sig is hilarious
James Turner
2017-06-28 07:27:35 UTC
Permalink
For this reason I will stop working on trying to use one of the common 3D formats unless someone can suggest one that supports x, y, z, u, v and intensity coordinates for each vertex and actually works correctly with OSG. All the code I used to generate the cylindrical projection can be found in https://github.com/viktorradnai/screenwarp/ including the patch for FlightGear, various ways of generating Warp files and a converter to the PLY format. I'd love to get my patch into FlightGear, although I understand that you might not want this until a proper 3D format is used. If you are interested in merging this. let me know and I'll raise a merge request.
I think we could merge the patch, just have a few comments:

- are the changes in createPanoramicSphericalDisplayDistortionMesh needed? They don’t seem to do anything?

- can you remove some of the logging you added, eg in CameraGroup::buildCamera

Aside form this I think the patch is pretty safe to merge, although since I have never used a distortion camera, I’m saying this purely based on code inspection.

Kind regards,
James

Loading...