Image horizontal mirroring

[Paul Bourke]

Can I humbly make a case for the horizontal mirroring to be re-enabled in NightShade, this is critical for use with the spherical mirror.

Actually, the current flipping seems a very strange default. Whether one does direct projection (projector-spherical mirror-dome) or indirect projection (projector - planar mirror - spherical mirror - dome) the current setting gives a mirrored presentation on the computer display (including guy elements). Since all projectors have the option to flip the image horizontally or not, it is the mirrored image on the computer display that is the real issue. Whether a particular installation uses direct or indirect projection is managed by the horizontal flipping in the projector.

I note that the last time this was discussed the reason given was performance. I dispute this since the mirroring is currently occurring from the implementation of the spherical mirror warping, thus just a -1 needed in the "right place", wherever the horizontal position of a vertex is being determined. If the image on the computer display was round the right way then actually an additional mirroring capability is unnecessary (I suspect).

This has affected the ability to use NightShade effectively in my last 5 installations
1. Manpal, India: http://paulbourke.net/exhibition/domeinstall/manipaldome1.jpg (indirect)
2. Bangalore, India: http://paulbourke.net/exhibition/domeinstall/bangalore1.jpg (direct)
3. Carnarvon, australia: http://paulbourke.net/exhibition/domeinstall/carnarvon1.jpg (indirect)
4. Terengganu, Malaysia: http://paulbourke.net/exhibition/domeinstall/terengganu3.jpg (direct)
5. Kuching, Malaysia.

[Rob Spearman (rob-digitaliseducation)]

Thanks for the explanation of the issue. This feature was dropped during a performance refactoring simply because I thought the feature was not used.

Why would anyone would want to show the GUI on the dome? I would instead recommend using the key commands and TUI in a planetarium type use. So is this still an issue...?

Rob

[Paul Bourke (paul-bourke)]

> Thanks for the explanation of the issue. This feature was dropped
> during a performance refactoring simply because I thought the feature
> was not used.

For all the instances I can imagine the flipping flags in the config
file can be dropped.
The problem is the current default horizontally flipped image.

> Why would anyone would want to show the GUI on the dome? I would
> instead recommend using the key commands and TUI in a planetarium type
> use. So is this still an issue...?

Absolutely and accept your point about the GUI ... I just used that as
an example of how frustrating it is to have to work with a mirrored
mage.

The preferred mode of operation for most sites is a HD display and a
projector, the two displays in "mirror" mode (too many uses of the
word mirror here :-)) ... the display and projector get the same
image. The operator sees and navigates using the computer display not
inside the dome.

--
Paul Bourke
Research Associate Professor
Director, iVEC @ University of Western Australia
Email: <email address hidden>
Office phone: [phone]
Mobile: [phone]
http://paulbourke.net

[Rob Spearman (rob-digitaliseducation)]

Thanks, that helps clarify.

All the existing Nighshade 11 code will be abandoned when Nightshade 12
is released later this year. We finally bit the bullet and are tossing
out all the limitations of the code inherited from Stellarium.

While this is generally an extremely positive development, we are in a
pickle for supporting spherical mirror projection. No one currently on
the Nightshade development team uses or understands this feature in any
detail.

We need someone to write up requirements for this feature. And we also
need a developer to step forward to completely reimplement and maintain
this. Otherwise the new version will be missing this feature.

Rob

[Paul Bourke (paul-bourke)]

> We need someone to write up requirements for this feature. And we also
> need a developer to step forward to completely reimplement and maintain
> this. Otherwise the new version will be missing this feature.

OK. I am available to define the requirements. As it happens, the
current approach which involves simulating the spherical mirror setup
is not the one I recommend. It is high maintenance. The approach that
I have developed and others (software bisque, QC, MaxMSP, Fulldome ...
) have adopted is a fairly simple one stage warping of the fisheye
using a textured mesh. And as I have mentioned before it is more
powerful than just spherical mirrors, it would enable other sorts of
lens corrections, even using NightShade with a fisheye lens in a
rectangular room. :-)

If the code is C or C++ and OpenGL then I can also offer code snippets
to make explicit some of the details. While I am a programmer I
unfortunately don't personally have the time to devote to this myself.

--
Paul Bourke
Research Associate Professor
Director, iVEC @ University of Western Australia
Email: <email address hidden>
Office phone: [phone]
Mobile: [phone]
http://paulbourke.net

[Rob Spearman (rob-digitaliseducation)]

Great! Thanks for volunteering.

Nightshade 12 is written mostly in C++ using OpenSceneGraph and OpenGL so code snippets would probably be helpful. Once we have requirements defined we will have a much better idea of how much work is involved.

I created a "Blueprint" on Launchpad where you can link to a requirements document and we can have a public discussion as needed. If you have any problems using that feature, just let me know.

Thanks!

Rob

[Paul Bourke (paul-bourke)]

> Great! Thanks for volunteering.

Just so you know, I've started on this but soooo busy, it will appear here
   http://paulbourke.net/miscellaneous/domemirror/warpingfisheye/
Still lots to do and the tricky part is object selection ... I hope to
work on this again this weekend.

--
Paul Bourke
Research Associate Professor
Director, iVEC @ University of Western Australia
Email: <email address hidden>
Office phone: [phone]
Mobile: [phone]
http://paulbourke.net

[Rob Spearman (rob-digitaliseducation)]

Great start. I put a link to the spec in the blueprint.

One question I had is whether any GUI components should not be warped.

Rob

[Paul Bourke (paul-bourke)]

> Great start. I put a link to the spec in the blueprint.
> One question I had is whether any GUI components should not be warped.

Good question.
As you pointed out earlier, the GUI is not helpful/appropriate on the
dome, but if required then it should be usable by the operator on the
operator display. On this basis I propose the GUI should not be
warped.

--
Paul Bourke
Research Associate Professor
Director, iVEC @ University of Western Australia
Email: <email address hidden>
Office phone: [phone]
Mobile: [phone]
http://paulbourke.net

[Paul Bourke (paul-bourke)]

I've added the next section on mouse clicking and selection.
--
Paul Bourke
Research Associate Professor
Director, iVEC @ University of Western Australia
Email: <email address hidden>
Office phone: [phone]
Mobile: [phone]
http://paulbourke.net

[Rob Spearman (rob-digitaliseducation)]

Great. Do you have more to add to your specification other than that
the GUI should not be warped?

Are we ready to get some more eyes on this for review?

Thanks,

Rob

[Paul Bourke (paul-bourke)]

> Great. Do you have more to add to your specification other than that
> the GUI should not be warped?
> Are we ready to get some more eyes on this for review?

Definitely, I need to know which parts are not clear or missing.
    http://paulbourke.net/miscellaneous/domemirror/warpingfisheye/
I'll have another look over it tonight and add anything I think of.

--
Paul Bourke
Research Associate Professor
Director, iVEC @ University of Western Australia
Email: <email address hidden>
Office phone: [phone]
Mobile: [phone]
http://paulbourke.net

[doctor-pat (reiff-rice)]

Hi, I read Paul's specifications, and as usual Paul is the expert here. Having an external changeable warped mesh would be very useful, for example, in using the elumenati Geodomes which are not a full hemisphere. (The standard warps look strange in that dome).

However, as a frequent user (and distributor) of warped content, I strongly suggest that the GUIs be unwarped and be placed along the TOP edge of the display (which can also include the left and right edges near the top). We do this in our "mediashow-mirror" software, (http://www.spaceupdate.com/img/software/scr_mediashow3.jpg) and so are visible on the console but are in the back of the dome so not visible to the audience. (Actually they are off the edge of the curved mirror) If they are then "autohide", they will only show when the cursor moves over them. However, that might harm performance, so we use a "D" key to toggle our menu bar on and off during the show. We make it red for obvious reasons.

Frankly I prefer that the console operator screen be either:

1. Warped and an exact duplicate of the projection screen. in this case the images are cloned on both the laptop monitor and the projector (WYSIWYG)
or
2. Unwarped and a control screen that is JUST a controller. In this case the projector is an "extended display". This is similar to our "mediashow-Pro" software. http://www.spaceupdate.com/?software-mediashow.html

The advantage of 1 is that the operator can view what is on the screen, and can capture images and even movies from running scripts. (we do this all the time in Stellarium, creating shows for folks who are not comfortable with scripting language).

The advantage of 2 is that the software can be run from a laptop that is not 1920x1080 (yes, there are lots out there), AND that the control screen can be readily mapped to an iPad to allow control from anywhere in the room. The buttons and text should be big in that case. It also allows for lower-performance computers since the graphic is not displayed on the control console.

That's why we offer both in Media Show and use both frequently, so actually both options are very nice to have.

One issue with 0.10.2 Stellarium (the latest one that warps properly), is that once you go to warped and set it as default, the gui's disappear offscreen and I can't access them in a show. Presumably by placing the GUI's later after warping that problem won't exist.