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
initial commit on including babylonjs in renderers' page #1247 #1298
Conversation
…ear model when switching scene 2. model's transform 3. loading model's reject call back
|
||
import {ScenarioConfig} from '../../common.js'; | ||
|
||
// const IS_BINARY_RE = /\.glb$/; |
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.
i don't know what does this variable do, i guess it's checking whether the model is glb or gltf? If that's the case I can just delete it because in Babylonjs you don't have to distinguish these two format
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.
Yes, that's right.
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.
I will delete this then.
</babylon-viewer> | ||
</renderer-harness> | ||
|
||
<!-- <script src="../../../node_modules/babylon/babylon.js"></script> --> |
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.
I probably need to use this line in next PR, so i just comment it here.
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.
Looking good! Also, go ahead and run update-screenshots
and commit those here as well so we can see how the goldens are comparing.
@@ -0,0 +1,151 @@ | |||
/* @license | |||
* Copyright 2019 Google LLC. All Rights Reserved. |
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.
This should be updated to 2020 since it's a new file.
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.
Ok, i'll fix it .
const $engine = Symbol('engine'); | ||
const $scene = Symbol('scene'); | ||
const $camera = Symbol('camera'); | ||
const $hdrTexture = Symbol('hdrTexture'); |
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.
I'm over these symbols. We need them in our top-level model-viewer API (the mixins) to keep private stuff mostly private since JS doesn't really have that concept. However, that style got applied somewhat slapdash through the rest of our TS codebase, which I think is unnecessary and ugly. I plan to rip these out of our files at some point, but if you'd like to start here you're welcome to. We can also leave it to a later date, but I want to make sure you're aware.
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.
Ok thanks. Actually I'm wondering about the reason of doing this as well. I will get rid of this later.
|
||
// load hdr directly | ||
this[$hdrTexture] = new HDRCubeTexture( | ||
scenario.lighting, this[$scene], 128, false, false, false); |
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.
What is 128?
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.
i think this is related to the issue i just posted. #1297 I just replied you there, can you see it there?
// load hdr directly | ||
this[$hdrTexture] = new HDRCubeTexture( | ||
scenario.lighting, this[$scene], 128, false, false, false); | ||
this[$scene].environmentTexture = this[$hdrTexture]; |
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.
If you don't use this hdrTexture anywhere else, you might skip the member and just put it directly here.
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.
That make sense. I will fix it.
|
||
private async[$updateScenario](scenario: ScenarioConfig) { | ||
if (this[$scene] != null) { | ||
this[$scene].dispose(); |
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.
I'm not familiar with Babylon, but does the scene require disposal while the engine does not? And how about the environment texture?
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.
Scene require disposal because if not, when the scenario changes, the former scenario's model is still in the scene. In the babylonjs's forum I found this is the recommended way to clear all models and meshes.
Engine seems to be independent of scene. it doesn't need to be disposal. I think in babylonjs everything is represented as tree node, so the engine is the root node and the scene is a child node of engine.
I think environment texture should be disposal because some scenario has different environment texture.
} | ||
|
||
private[$render]() { | ||
} |
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.
Is this necessary?
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.
Yeah, i need to write an event listener here in next PR . Basically it's to tell the index page that the rendering is done and you can go ahead.
constructor() { | ||
super(); | ||
} |
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.
Not sure what the code style is for this repo, but this constructor is unnecessary.
const alpha = orbit.phi * Math.PI / 180; | ||
const beta = orbit.phi * Math.PI / 180; |
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.
Did you mean to use orbit.phi
here twice?
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.
Oh it's a mistake, thank you for pointing out that for me!
scenario.model.substring(lastSlashIndex + 1, scenario.model.length); | ||
|
||
await new Promise((resolve) => { | ||
SceneLoader.Append(modelRootPath, modelFileName, this[$scene], () => { |
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.
SceneLoader.AppendAsync
returns a promise, so I think instead you could do:
await SceneLoader.AppendAsync(...)
That being said, it's unclear to me what the difference is between Append
and AppendAsync
.. maybe Append
is already synchronous?
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.
i'm think you are right. I will replace that with the AppendAsync function. Thanks for the comment!
LGTM. |
…include-babylon-renderer-page
66744e6
to
d09d168
Compare
7719d38
to
5cd6fd5
Compare
private[$scene]: Scene; | ||
|
||
|
||
connectedCallback() { |
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.
These empty callbacks can also be removed.
|
||
const {orbit, target} = scenario; | ||
const alpha = (orbit.theta + 90) * Math.PI / 180; | ||
let beta = orbit.phi * Math.PI / 180; |
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.
Can this be const instead?
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.
oh i forgot to change that. At first I saw in babylonjs's document that there'll be error if beta is set to 0 or PI, so I added a condition to added 0.1 offset. But i found it's actually correct without this condition, so i guess babylon has did this conditional offset themselves and I just delete it. Thank you for finding that !
const hdrTexture = new HDRCubeTexture( | ||
scenario.lighting, this[$scene], 256, false, false, false); | ||
this[$scene].environmentTexture = hdrTexture; | ||
// rotate both skybox and hdr texture for 180 deg to match other renderers |
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.
I might say skybox and environment, to match model-viewer terminology.
|
||
this[$scene].executeWhenReady(() => { | ||
requestAnimationFrame(() => { | ||
requestAnimationFrame(() => { |
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.
Was one raf not enough?
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.
i just copied this code from filament-viewer.ts, here is the origin code. I actually don't understand why need two rafs
// Wait two rAFs to ensure we rendered at least once:
requestAnimationFrame(() => {
requestAnimationFrame(() => {
this.dispatchEvent(
new CustomEvent('model-visibility', {detail: {visible: true}}));
});
});
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.
i tried one raf and both update screenshots and fidelity test are successful. So i will just change it to one raf, is that ok?
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.
Sounds good.
<head> | ||
<meta charset="UTF-8"> | ||
<meta name="viewport" content="width=device-width, minimum-scale=1.0, initial-scale=1.0, user-scalable=yes"> | ||
<title>Filament Fidelity Tests</title> |
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.
Babylon?
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.
That's silly, thank you for finding that!
5cd6fd5
to
2c8be0f
Compare
…into include-babylon-renderer-page
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.
Thanks, looks great! Next thing will be to use Babylon's environment prefiltering so these look halfway decent.
Reference Issue
Fixes #1247 ,#1297, #1296