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

PBR, Streaming and LOD #596

Closed
selim-bekkar-sb opened this issue May 19, 2016 · 8 comments
Closed

PBR, Streaming and LOD #596

selim-bekkar-sb opened this issue May 19, 2016 · 8 comments

Comments

@selim-bekkar-sb
Copy link

Hi everybody,

Firstly, I want to thank all the WebGL/glTF community for his work (libraries, documentations, tutorials…).

I’m actually working on a viewer using ThreeJS, and all my scenes will be glTF files. I’m trying to allow asset streaming, support Physically Based Rendering and LOD. I would like to ask you some questions and know your opinions. If my work can be benefit to the community instead of resolve only my own problems, it will be more enjoyable and motivating.

About PBR:
Since ThreeJS have a “MeshStandardMaterial” (thx for this add! ), it’s seems interesting to have a glTF extension (or increase the KHR_materials_common) to describe StandardMaterial proprieties instead of sending all the shader and translate it into ThreeJS. Something is on this way ?

About LOD:
I have not seen anything that talks about it. What do you suggest to not disturb the current loaders ?

About the stream:
Let me start by explain what i’m trying to do: There is a diagram showing what i’m actually doing ( I hope this is enough explicit to understand the behavior).
rest3d stream

I’m using node.js with websocket-stream module.
The main idea is to send the most essential informations in first. By essential informations i mean which object is the most representative in our asset and which data are most representatives in this object. That why meshes are sort and “position” attribute is sent in first.
The goal for the user is he understand as quickly as possible what this asset represent, even if the global process to transfert all the file is a little bit slower than “classic” approach.
Some problems are coming:

  1. If the model has his faces described by vertex indices, i need to wait the stream of indices to build my surface. So with this configuration i need to dereference my faces before sending it. It’s not very smart to do it every time by the server, and probably not more pertinent to create my own file format. Thus I think that it will be more efficient to doing this one time directly in the collada2gltf exporter (by adding an option ?).
  2. Also why not to provide a option to interlace the data ?
  3. Because the vertices are received in the same order as they was read in the binary file, maybe it could be interesting to sort them by some criteria ? area, orientation ( I mean if we know the face orientations, and the camera direction, we can statically skip 50% of all faces )…

Thank for you attention. And feel free to say what you are thinking, especially if I said bullshit :)

ping: @RemiArnaud

@pjcozzi
Copy link
Member

pjcozzi commented May 19, 2016

Thanks for the kind words.

About PBR...Something is on this way ?

We are interested in this! See Slide 14 here and perhaps talk to @mlimper about collaboration.

As for the LOD and streaming, I don't have any glTF-specific advice, but glTF should be flexibility enough to offer you plenty of options. For example, for HLOD for geospatial datasets, we are building 3D Tiles, where each tile in the spatial data structure is basically a glTF asset.

For interleaving, it would be a welcomed contribution to COLLADA2GLTF or perhaps gltf-pipeline.

@selim-bekkar-sb
Copy link
Author

Thx for your answer.

I will fork COLLADA2GLTF soon to add interleaving and sorting options.

@pjcozzi
Copy link
Member

pjcozzi commented May 26, 2016

Sounds great, looking forward to your contribution!

@pjcozzi
Copy link
Member

pjcozzi commented Jul 9, 2016

See #643 for PBR.

@selim-bekkar-sb
Copy link
Author

FYI: This protocol is know available at: https://github.com/fl4re/rest3d-new
It still in progress, but usable.

Any feedback is welcome :)

@RemiArnaud
Copy link
Contributor

Could you please add link to github in the presentation, also cross reference presentation in github.

Thanks

-- Rémi

On Aug 9, 2016, at 12:51 PM, selim-bekkar-sb [email protected] wrote:

FYI: This protocol is know available at: https://github.com/fl4re/rest3d-new
It still in progress, but usable.

Any feedback is welcome :)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@pjcozzi
Copy link
Member

pjcozzi commented Dec 23, 2017

For LOD, see #1045

For streaming, see https://github.com/thibauts/pop-buffer and 3D Tiles (separate but built on glTF). For more streaming discussion, let's start a new issue.

@pjcozzi pjcozzi closed this as completed Dec 23, 2017
@ProFive
Copy link

ProFive commented Feb 9, 2018

FYI: This protocol is know available at: https://github.com/fl4re/rest3d-new
It still in progress, but usable.

Any feedback is welcome :)

Load streaming only glTF 1.0. Do you have a example load streaming glTF 2.0 ?

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

No branches or pull requests

4 participants