Skip to content
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

fix case where removing texture (null was not equal to empty string) #2393

Merged
merged 5 commits into from
Feb 16, 2017

Conversation

machenmusik
Copy link
Contributor

Fixes #2388

@machenmusik
Copy link
Contributor Author

easiest way to test - run local instance with this change via npm start, and load @fernandojsg's codepen on same machine, changing aframe script src to http://localhost:9000/build/aframe.js

@ngokevin
Copy link
Member

Can we add unit tests? Both for setAttribute('material', 'src', '') and removeAttribute('material', 'src').

@machenmusik
Copy link
Contributor Author

ok, LGTM now...

@machenmusik machenmusik force-pushed the fix-clearing-material-src branch from c390d7a to 35fe67a Compare February 16, 2017 20:20
@machenmusik
Copy link
Contributor Author

@dmarcos take a look at latest? should be much more comprehensible

@machenmusik
Copy link
Contributor Author

specifically, latest added comments try to better explain why having a single remembrance of last texture load attempt is insufficient, per discussion on #2402

el.sceneEl.systems.material.loadTexture(src, {src: src, repeat: data.repeat, offset: data.offset, npot: data.npot}, setMap);
if (!src) {
// Forget the prior material src.
shader[shadowSrcName] = null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would not be better to store all the material src within an object and not hanging directly from the shader with a strange __texture__ key? Something like shader.materialsSrc = []

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought that the developers can arbitrarily define and use anything in the shader property namespace, so was trying to avoid collisions by using unlikely-to-collide naming, though I could be wrong. Maybe it is better to make a map with name that is unlikely to collide as you suggest, although as it is internal, I thought usual convention was to use underscore prefix.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can then append it to the shader.material object. Safer than a strange key

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I was in there, really we don't care about the data property name, we care about the material property name, which is what we use to actually set the texture.

@machenmusik
Copy link
Contributor Author

LGTM... @dmarcos ?

@dmarcos
Copy link
Member

dmarcos commented Feb 16, 2017

Thanks!

@dmarcos dmarcos merged commit 6160cb5 into aframevr:master Feb 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants