khronosgroup / gltf Goto Github PK

In order to be able to regenerate shader from the parameters, it is required to associate the slot say diffuse, ambient... to a mesh attribute semantic (TEXCOORD_0, TEXCOORD_1..).
The semantic mentioned above follow the convention from the note "Notes about shaders" in the SPEC, this same note should be updated.

There is parameters, but not the entries which are object

by batching together geometries sharing the same material.

Patrick's proposal:

• Renamed x-shader/x-fragment to fragmentShader to better match WebGL
• Renamed x-shader/x-vertex to vertexShader to better match WebGL

That's in the SPEC now, but this is out of sync with the converter.
Before updating the converter we should agree here.

I believe the first naming was fine, it is widely used as a convention.
I don't see how "vertexShader" and "fragmentShader" are more a match with WebGL, I could find an occurence of this naming in the WebGL SPEC.

Moreover, the WebGL Wiki (from Khronos) refers also to x-shader/x-fragment:
http://www.khronos.org/webgl/wiki/Tutorial

We agreed to start conservative by doing so, though we are aware it can be not convenient for points. Keep track of this here for now.

Rename as discussed via email...

I'll update the spec now, but we still need to do file/directory renames in the converter. Please update the links in the spec after the renames.

In our quest to balance simplicity and flexibility, I'd like to open the discussion for if glTF JSON should be able to reference other JSON. This would be useful for storing large node hierarchies across several files, where only a few of them may need to be loaded based on visibility, LOD, etc. It would also be useful for sharing parts of the JSON, e.g., materials, among multiple assets, which can reduce overall bandwidth.

I'm happy to draft up some example JSON (probably after GDC).

My feeling on this is yes because of the above use cases and that it matches the flexibility with everything else in glTF - buffers, images, and shaders.

I'm interested in other thoughts...

The glTF validator based on the glTF schema is a good start, but JSON Schema doesn't allow for precise validation like XML, e.g., it doesn't consider the interaction between properties.

We'll need a more comprehensive validator, perhaps written in JavaScript with node.js, available as a developer library, command line tool, REST API, and web interface.

Hello, what is recommended compiler for Converter build? I use VS 2010 on Windows 7 64b. and i followed wiki instructions with cmakelists but there are few errors i cant solve easily:

"Error 1 error C2065: 'Writer' : undeclared identifier C:\WWW\BP_3\glTF\converter\COLLADA2GLTF\dependencies\OpenCOLLADA\COLLADAValidator\src\main.cpp 33 1 OpenCOLLADAValidator
Error 2 error C2146: syntax error : missing ';' before identifier 'writer' C:\WWW\BP_3\glTF\converter\COLLADA2GLTF\dependencies\OpenCOLLADA\COLLADAValidator\src\main.cpp 33 1 OpenCOLLADAValidator
Error 3 error C2065: 'writer' : undeclared identifier C:\WWW\BP_3\glTF\converter\COLLADA2GLTF\dependencies\OpenCOLLADA\COLLADAValidator\src\main.cpp 33 1 OpenCOLLADAValidator
Error 4 error C2065: 'writer' : undeclared identifier C:\WWW\BP_3\glTF\converter\COLLADA2GLTF\dependencies\OpenCOLLADA\COLLADAValidator\src\main.cpp 35 1 OpenCOLLADAValidator
"

This class 'Writer' is completly missing. Am I missing something? Thank you.

Might be already the case - need to check

Given that glTF strives to be cross-platform and cross-device, what endianness considerations do we need for binary data?

Potential options:

1. buffer contains a property that says if the referenced buffer was authored as big or little endian.
2. glTF define that binary data is always big or little endian.
3. (1) + suggest negotiation via REST API (or at conversion time). (1) and (2) alone imply that the application may have to swap bytes, which goes against our design principle of minimal processing in the application.

We can't just ignore this completely, right? I am leaning towards (3).

Ignoring texture compression for the moment, I currently wrote the spec to support the following image formats because these formats are natively supported by modern web browsers: .jpg, .png, .bmp, and .gif.

However, I see little value in supporting .bmp and .gif especially since it could increase the burden for OpenGL and OpenGL ES users using C++.

Do we agree that just .jpg and .png are sufficient (again, ignoring compression)?

Also, I believe the spec should explicitly mention the formats since, for example, COLLADA allows for any image format, which makes it really hard to write a renderer and know it is going to work on all models.

We need to cleanup our use of git submodules so we are using explicit versions of submodules. This way we always know the state of the glTF repo and that it builds and runs successfully.

Instead of suggesting that users run:

git clone https://github.com/KhronosGroup/glTF.git
cd glTF
git submodule update --init --recursive

They should clone with just:

git clone --recurse-submodules https://github.com/KhronosGroup/glTF.git

Then, we should only update a submodule to known compatible versions explicitly using pull requests with a command line like:

git checkout -b updaterapidjson
cd glTF/converter/dae2json/dependencies/rapidjson
git pull origin master
cd ..
git add rapidjson
// commit and push as usual.

Then users who already cloned, do the following to update submodules:

git submodule update

We can close this issue when all submodules are updated to a known state and README.md (or the right location) is updated to reflect these instructions.

What is recommended web browser to view /webgl/* apps and examples? Only Opera seems to be working, but too slowly ... Chrome nor Firefox isn't working. Thank you.

let's show (nice graphics?:) where glTF stands in the eco-system.
COLLADA, Rest3D and so on...

This is a new github label for developer outreach ideas, e.g., demos, publications, presentations, etc. Anyway...

When glTF stabilizes, it would be good to show some size and speed comparisons to COLLADA or even other formats to help motivate glTF. Even compare amount of code needed to write a renderer. Perhaps we can use Three.js, which already supports other formats for the load speed comparisons.

just copyright is not enough, in many COLLADA files we get the autoring_tool. We should probably propagate this information.
We should also gave a property to specify which converter is being used to produce a given glTF asset.

Putting for the record other Patrick thoughts here:

• Also need url for copyright image?
  • COLLADA2JSON
• Create asset.copyright from COLLADA author and copyright?. <Fabrice +1 for that>
• Convert COLLADA geographic_location. glTF uses radians, not degrees.
• Convert kml/kmz location to geographic_location. Convert kml/kmz orientation and scale to a transform.

need clarification about which semantic should be mandatory.

The POSITION is special in the sense it is the attribute to be used for represent the mesh in space. So at least for a viewer getting data from a content provider, if both implement the SPEC without knowing any of the meaning of the SEMANTIC a viewer could render the mesh but it would not be able to perform frustum culling if POSITION is not implemented.

So I would advise that POSITION should be mandatory and always implemented.
All the other semantics being used lighting model computation/skinning... should just proposal.

That said, there is a note that advice to implement the suggested set to be able to re-generate the shaders.

A clean website with links to the whitepaper, spec, demos, etc.

Our github repo is great, but we'll need something more forward-facing for the masses.

url: http://gltf.gl/

Currently we have a couple of { semantic, set }.

Patrick suggested we could use a parsing convention like "semantic.set" so that we get a single property. Some implementation experiments and/or community feedback welcomed before changing this.

I'll have a spec proposal soon, but we need to be careful not to decouple images and image filters because this is not supported in WebGL and OpenGL ES without duplicating the image, which is painful on the client.

The fix could be as simple as the spec disallowing multiple textures to be bound at the same time with different filters. Otherwise, this requires GL_ARB_sampler_objects.

I'll think about it a bit more before proposing something...

Hello, is there some kind of support for animations in Collada2Json converter? I can't get it working when exporting .DAE from Blender. Thank you!

There should be a converter option (off by default) to minify the JSON created to reduce its size.

There are several JavaScript minifiers available, but given that we can't change the names of any of the JSON properties, we probably just need to remove whitespace, which we won't need a third-party minifier for.

COLLADA has both id and sid. id is globally scoped and sid is locally scoped to its parent.

id corresponds to glTF's property names (as opposed to the name property used by external applications), e.g.,

"id" : {
    "name" : "propertyName"
}

sid is useful for reusing animations, for example. We should be sure that the converter supports it.

I don't believe this needs a glTF specification update. Do you agree @fabrobinet?

We should migrate all relevant issues from the old collada2json github to the glTF github.

All converted scenes should come with the same axis-up. Y-UP.

some huge models have issues with split.
It's like 90% of the geometry is OK though.
I'll check this quickly

Once glTF stabilizes, as part of our outreach, we should write a two-page whitepaper describing glTF.

When glTF reaches 1.0, the default profile should not be WebGL 1.0. Instead, it should be the latest WebGL 1.0.x spec to make sure we include any updates for security, etc.

I added a new github label for stages in an optimization pipeline that would be part of the converter and standalone as we discussed.

This issue is to investigate integrating a GLSL optimizer - https://github.com/aras-p/glsl-optimizer

To reduce asset size, the converter should have an option (off by default) to minify the generated GLSL.

Removing whitespace and comments is obvious (that is actually all my WebGL engine does now), but minification can be much more aggressive by renaming functions, variables, and even uniforms (and the glTF JSON) in the extreme case.

We can investigate some tools:

• https://code.google.com/p/glsl-unit/wiki/UsingTheCompiler (online version, discussion)
• http://www.ctrl-alt-test.fr/?page_id=7 (online version)
• https://github.com/chrisdickinson/glslmin
• Cesium script for removing whitespace and comments. https://github.com/AnalyticalGraphicsInc/cesium/blob/b19/Tools/buildTasks/extractShaderComments.js

For now, let's use this bug to decide how extensions should be specified.

From Patrick comments.
"Consider support for UNPACK_FLIP_Y_WEBGL, UNPACK_PREMULTIPLY_ALPHA_WEBGL, and UNPACK_COLORSPACE_CONVERSION_WEBGL._"

We discussed previously about adding a Profile information.
Something like "API x.x" for instance "WebGL 1.0"

This isn't clearly mentioned yet in the schema/documentation.

This prevent us to check alpha channel of images in the converter at the moment.

Currently a parameter has types such as SAMPLER_2D , FLOAT_VEC etc...

SAMPLER_2D currently has an image property, it is too naive. we need to change this, we want to handle video too.

Some more aspects to discuss:

• We also want to be able to declare samplers not tied to an image for offscreen rendering.
• Additionally, how will we declare cube maps ? for the type it's easy, there is SAMPLER_CUBE. For the 6 images, let's see where they would fit...

During last discussion Remi proposed to bring back the surface concept from COLLADA.

• it's a good place to specify width/height for offscreen rendering
• It looks appropriate to declare the 6 images required for CUBE_MAP
• within the surface we could have a "source" property that would be to either a uniqueID which can be an image or a video (that's close to Remi proposal too, but that wouldn't be a path directly). when the type of surface would be cube we would have a "sources" property that would take an array of 6 unique IDs. (like for image&video).
  In surface, "source" would have a different meaning than in COLLADA but I believe it wouldn't be confusing.

Also, currently parameter short-cut the indirection that COLLADA has for sampler.
And so far it looks fine this way.

I believe we should give a try at adding surface.
I'll attach soon a JSON example here.

I'd like to add scene to the spec. Should we allow a glTF asset to contain multiple scenes? Or is this something that should be negotiated via a REST API?

I'm somewhat on the fence, but I believe the flexibility allowed by multiple scenes and the potential it brings to reduce the total number of round trips, makes it valuable compared to its downside, which is a slight increase in complexity.

Thoughts?

We should make sure that the glTF spec covers everything in the old collada2json wiki (for the most part, it already does), and to create issues for relevant outstanding issues mentioned on that page.

Ultimately, we should remove that wiki page to avoid confusion.