-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sun #764
Conversation
Conflicts: Source/Scene/SceneTransitioner.js
…e sun is visible.
* // GLSL declaration | ||
* const float czm_solarRadius = ...; | ||
*/ | ||
// use toExponential instead of toString to prevent a number like 1.2e2 from expanding to 120 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we do this for all GLSL built-ins as a best practice? E.g., to avoid copy/paste errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we care about the textual length of these numbers? toExponential will often be larger than toString, e.g. for Math.PI. Also, wouldn't 1.2e2
still be considered an int? Don't you want to instead use like a F
or D
suffix on the literals like in most languages? I don't know GLSL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So apparently in C++/C#, only floating-point/real literal syntax allows exponential notation, even if the number would be integral, and even if the number doesn't have a decimal, e.g. 1e0
is a double in C#. Well, now I know.
}; | ||
} | ||
|
||
scene._fullScreenCommand.renderState = context.createRenderState(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even though createRenderState
does a cache lookup. It is still expensive since it needs to generate the key and search. These calls to createRenderState
actually show up on the profiler:
Render states are not really meant to be dynamic like what we are doing with the scissor test below. However, that is a common use case that is going to become more important as we do more post-processing/deferred stuff. I think we can treat the scissor test as a special case so we can keep the render state optimizations we already have and still serve this case. Let's discuss.
The profiler isn't too scary for this. Do you have before/after performance numbers on a desktop? Have you tried this on mobile? Should it be off by default? |
command = entireFrustumCommands[commandName]; | ||
if (typeof command !== 'undefined') { | ||
boundingVolume = command.boundingVolume; | ||
if (typeof boundingVolume !== 'undefined' && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even though we know no one is using it yet here, we should still probably check command.cull
to save us pain later.
There are issues interacting with picking. Run the Sandcastle picking example and select "Layer Primitives", and the sun will flicker on mouse over, which executes a pick. |
JSHint is happy. The (somehwat incomplete) tests pass. Once we handle the above issues, I'll take a second pass over this. |
The version in master is running at 181 fps. This version with the sun visible is running at 176 fps. |
Great. That is basically free - as least under the GPU load for the default globe. |
Conflicts: CHANGES.md
On the Asus tablet, the version in master runs at 13 fps and this version with the sun visible is 8 fps. |
Just keep in mind that the Asus tablet we have is particularly slow and several years old. I haven't checked stats on my phone, but I can check out the sun branch tonight if you care. |
@pjcozzi This is ready. |
Wonderful. Merging. |
Adds sun visualization in 3D and Columbus view.