-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
vc.gltf technique2 erroneous rendering #576
Comments
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. |
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
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) ) |
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. 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). |
@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. |
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. |
@kbirk Awesome! Thanks for the update |
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
which means
which means |
Also see donmccurdy/three-gltf-viewer#47 |
@donmccurdy perhaps OK to close this? |
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. |
Moving to KhronosGroup/COLLADA2GLTF#146. |
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 thevc.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 termcam
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:The rendered ouput seems to be correct:
Can this be confirmed as an model error?
The text was updated successfully, but these errors were encountered: