Branch/component relative resources

[allisoncorey]

@davideaster Humvee-lesson and radio-lesson still are not working with relative paths:

Ex. ../radio/radio.vwf

It seems to be ignoring the "../" prefix. Both radio/radio.vwf and ../radio/radio.vwf point to /radio-lesson/radio/radio.vwf, while /radio/radio.vwf points to /radio/radio.vwf.

However, this fixes the relative component path issues within the app folder itself, so I'm going to go ahead and merge to development. I will open a separate issue for the lesson apps.

[davideaster]

../radio/radio.vwf seems to be working for me in /demos/radio-lesson. What happens in resolveURI in vwf/utility.js when uri is ../radio/radio.vwf?

[davideaster]

For the image reference errors from the radio, the radio pre-loads its texture images, but the relative references only work when the radio component is the application. This is in radio.vwf.yaml in preloadImages.

Since radio-lesson.vwf merges radio.vwf during the include, the component doesn't have a base URI to use to resolve these references correctly. For other references that may be part of the component descriptor (extends, source, ...), the kernel resolves these before merging the descriptors during the include.

We might have to remove the preloader. If there's some way the radio can detect when it's included from somewhere other than its natural location, it could only omit the preloaded then.

[allisoncorey]

On a.href = uri,

uri = ../radio/radio.vwf.

After the assignment,

a.href = http://localhost:3000/demos/radio-lesson/radio/radio.vwf

[allisoncorey]

The radio images were originally absolute paths, which we could probably go back to. We'd just have to assume the parent directory is called "demos". I'm still working to load a relative path to radio from radio-lesson to test.

[davideaster]

The body is black, but I don't have any texture load errors except for lcd.png. All of the other textures seem to load correctly.

lcd.png is loaded dynamically in radio.vwf by:

this.Radio.LCD.material.texture = "images/lcd.png";

That's the same problem as preloading: code in an included component doesn't have any context to make relative references.

[davideaster]

In resolveURI, what does this show right before return a.href?

uri == "../radio/radio.vwf" && console.warn( "resolveURI", uri, baseURI, base && base.href, a.href );

I get:

resolveURI ../radio/radio.vwf /demos/radio-lesson/index.vwf http://localhost:3001/demos/radio-lesson/index.vwf http://localhost:3001/demos/radio/radio.vwf

[allisoncorey]

resolveURI ../radio/radio.vwf http://localhost:3000/demos/radio-lesson/eIrkh0MDx4x2s0jZ/index.vwf http://localhost:3000/demos/radio-lesson/eIrkh0MDx4x2s0jZ/index.vwf http://localhost:3000/demos/radio-lesson/radio/radio.vwf

[allisoncorey]

I'm going to pull down a fresh copy of development and the apps repo to see what happens. Maybe my clones are just confused :confused: <-- official confused smiley

[davideaster]

That baseURI should come from var baseURI = vwf.uri( childID, true ) in vwf.js at line 2301. If vwf.uri is returning the document URL, that would be puzzling. It might be possible something like this could happen if branch/absolute-application-url isn't applied correctly, although I don't really see a path for it.

[allisoncorey]

The vwf.uri is returning the document URL for me on a fresh clone of the repo.

For the black body texture on the radio, it loads correctly the first instance load on a newly started server. All subsequent connection show up black. The adl/assetCacheMaterialTest app shows black textures on the second models, which is probably related.

[allisoncorey]

test/lookAt has some interesting behavior too: On the second client join, the ducks snap to a different location. Additionally, the second client has darker lighting. If I reload the session a second time on a running server, I get the darker lighting.

[allisoncorey]

Should this type of model definition work in a script? I can't tell if it's because of the issue I'm seeing with baseURIs or if we need to change how these apps work.

var newMarbleShooterDef = { 
      "source": "models/" + marbleType.shooterModel, 
      "extends": "http://vwf.example.com/node3.vwf",
      "type": "model/vnd.collada+xml",
};

[allisoncorey]

I'm documenting all current issues on development in https://github.com/virtual-world-framework/vwf/issues/462

[davideaster]

It should be OK. The path is resolved relative to the node creating the child. It uses the same baseURI though, so problems with baseURI will propagate.