vc.gltf technique2 erroneous rendering

[kbirk]

I seem to be rendering some odd cubes in the vc.gltf sample scene. I noticed that there are many issues referenced in #556 for the vc.gltf file and was hoping if anyone could confirm that these cubes may be a result of errors in the file rather than errors in my implementation.

Here are some screenshots from various cameras:

All of the erroneous cubes are rendered via technique2 and have the term cam in the mesh name which leads me to believe that these are all the camera nodes.

By modifying the vc2FS.glsl fragment shader output to disable rendering these camera meshes:

gl_FragColor = vec4(0., 0., 0., 0.); // color;

The rendered ouput seems to be correct:

Can this be confirmed as an model error?

[lasalvavida]

Hello @kbirk!

As best I can tell these errors aren't present in Cesium, though I can't speak for your viewer.

I have a branch on my fork where I am currently fixing errors in the sample models which has a fixed version of VC.gltf

https://github.com/lasalvavida/glTF/blob/fix-sample-models/sampleModels/VC/glTF-Embedded/VC.gltf

Give that a try.

[MarcoHutter]

Whether it's a confirmation or not: I noticed the same boxes:

The renderer is a very early, experimental Java renderer, so take it with a grain of salt, but at least, these boxes are there. They are flying alongside the ships during the animation. Maybe I'll dig through the input file to see exactly where they come from.

(BTW: Some other things, e.g. the fact that

techniques>technique2->states>functions->depthMask

should be a boolean array (and not a single boolean) according to the spec ( https://github.com/KhronosGroup/glTF/blob/master/specification/schema/technique.states.functions.schema.json#L87 ) has already been pointed out in #556 (comment) )

[kbirk]

@lasalvavida

Thanks for the response.

I pulled the latest models from your repo, they render the same. Does the rendering implementation in Cesium include the provided glTF shaders / state information? (I'm not sure if Cesium is proprietary so feel free to omit a response). Would you be able to provide a screenshots of how it is supposed to look when correctly rendered? It would be very informative.

@MarcoHutter

Thanks for providing those screenshots.

I ran into the non-array function value as well, and have a temporary conditional to wrap them in the case that they are not arrays (hurray for javascript).

[lasalvavida]

@kbirk, Cesium is open source. I think the particular file that would be of interest to you is Model.js which defines how Cesium loads gltf files.

There's also the 3D Models example in Cesium Sandcastle that may help as well.

It sounds like this is probably an issue in your renderer, however the fact that you aren't the only person to have this issue means that there's probably some ambiguity in the spec that should be clarified.

[kbirk]

Sorry for the delay in my response.

I've taken a look at the code you've provided and from a high level view it seems to be similar to my implementation in how the format is loaded at runtime and the implementation of the techniques.

The major difference between the two is the order in which the meshes are rendered.

In my implementation I simply render the nodes depth first. As a quick sanity check, I rendered breadth first and compared. While the final output was still incorrect, it was different across the two traversal algorithms. This is to be expected when using any of the WebGL state functions that would cause order-dependent results (in this case blending and depth-masking).

I notice Cesium uses a more sophisticated rendering system in which DrawCommands are assembled and (I assume) are then sorted based on some priority of technique, shader, state, depth, transparency, etc.

I'm assuming this is the cause of the incorrect renderings. When I have some free cycles I'll implement a similar approach in my viewer and post my results.

[lasalvavida]

@kbirk Awesome! Thanks for the update

[javagl]

After investigating this a bit, I found out that the fact that the boxes are not visible in Cesium seems to be caused only by the Order-Independent Transparency rendering. When pragmatically disabling OIT, the boxes are also visible:

I still think that this is due to an error in the input file. The technique.states.functions contain

"blendFuncSeparate": [ 1, 771, 1, 771],

which means GL_ONE and GL_ONE_MINUS_SRC_ALPHA, whereas I think that they should be

"blendFuncSeparate": [ 770, 771, 770, 771],

which means GL_SRC_ALPHA and GL_ONE_MINUS_SRC_ALPHA. But if this is the case, then it would rather be a problem either of the original DAE input file, or the converter.

[pjcozzi]

Also see donmccurdy/three-gltf-viewer#47

[pjcozzi]

@donmccurdy perhaps OK to close this?

[donmccurdy]

Issue still occurs, from @javagl's comment above it sounds like it's either (a) a bug in the input COLLADA model, or (b) a bug in COLLADA2GLTF.

[donmccurdy]

Moving to KhronosGroup/COLLADA2GLTF#146.