Bad/Missing docs for useDirectMapping

I found only little information in the docs:

Use a direct mapping technique to render the video. You should leave this value on unless you want to use the fovMultiplier property

Unfortunately I set this to false in my Application (which was unnecessary, because I only set the fov of the camera, not the fovMultiplier of the PhotoDome).
But now I found out that the imageMode has no effect (i.e. only MODE_MONOSCOPIC images can be used): Example.
So I must set useDirectMapping back to true, which also causes many issues:

  • the initialView will show a different part of the image: Example
  • the initialAlpha value of the ArcRotateCamera has no effect: Example
  • all the points and directions that we had stored in the database are now in a different location

I think the documentation should show a clear warning for that setting and go into more details, what this is used for and what the consequences of changing the setting are.

cc @RaananW, because I think he wrote the PhotoDome (?) class.

However, I’m not sure about the question? This parameter affects how the texture is projected, so we’d expect the behavior to be different:

        if (this._useDirectMapping) {
            this._texture.wrapU = Texture.CLAMP_ADDRESSMODE;
            this._texture.wrapV = Texture.CLAMP_ADDRESSMODE;
            this._material.diffuseTexture = this._texture;
        } else {
            this._texture.coordinatesMode = Texture.FIXED_EQUIRECTANGULAR_MIRRORED_MODE; // matches orientation
            this._texture.wrapV = Texture.CLAMP_ADDRESSMODE;
            this._material.reflectionTexture = this._texture;
1 Like

Reminder that the documentation is open source too so everyone can update it :saluting_face: We miss stuff there sometimes so contributions are always welcome :smiley:

1 Like

A few things - I am not soo sure what you mean by “have no effect”. You are loading a side-by-side image, and you only see one view of it, meaning - side by side is working. There is an difference in rendering because of the different parameters passed to the underlying texture.

initial view is different because of different mapping
initial alpha DOES influence the initial view (not sure why you say it isn’t?).

Improving the docs is always an open task, and we are doing our best to do that :slight_smile: And I willbe happy to review a PR that improves the current docs of the texture dome, i am just not sure which part is incorrect

A small note regarding your use case - The TextureDome (and the photodome/videodome that inherit from it) it meant as a way to display a sphere and attach a texture to it. You are manipulating it in your application to allow zooming (which is awesome), so maybe you need a little more than the texture dome. Implementing the usecase on your own is sometimes an acceptable solution, especially if the default parameters don’t allow you to do what you intend on doing.


You are right - initialAlpha is working fine: I think I may have messed up my tests - sorry.

Thanks, for the info. I’ll study the source code and may come back if I have more specific questions.