-
Notifications
You must be signed in to change notification settings - Fork 565
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
Porting a minimalist OpenSubDiv to JavaScript? #247
Comments
I did just notice this, but I am not sure what to make of it: https://github.com/takahito-tejima/webgl/tree/master/opensubdiv |
Hi Ben, thank you for your interest in OpenSubdiv! I think porting OpenSubdiv to Javascript/WebGL environment can be split into two big chunks of work. (assuming only uniform subdivision will be used for this purpose. You don't need to port adaptive tess shader code unless doing something beyond my imagination).
My prototype only covers 2, and there are a lot of questions how to get 1. If the application is kind of animation playback tool (including game), step 1 can be performed on server-side or at build time because subdivision tables only depend on topology, which is relatively fixed. But for the modeling applications like yours, it wouldn't work. I'm not sure how emScripten like solution can be applied here, but it definitely sounds an interesting approach. There hasn't been a public port of OpenSubdiv into JavaScript, as far as I know. And yes I'm very interested in! |
I think I nearly have an OpenSubdiv emscripten build working: I have This pull request to emulate glew looks promising ( Once the simpleCpu example runs (and I will likely hit more snags once I I suspect it will also be super slow, being single threaded, but perhaps So, still quite a bit to do, but it seems within reach. Jeremy |
@takahito-tejima Interesting. Thanks for the explanation. I think we are most interested in a CPU-only implementation that we can just optimize (likely via web workers as @jcowles suggests.) @jcowles Of course you are working on an enScripten build already. heh. How large is the enScripten build for simpleCPU even if it is crashing? I am always concerned about the size of enScripten results. In know that the Unreal Engine 3 demo was more than 23MB of enScriptened produced JavaScript, which is a pretty scary size. Also, I am confused as to why glew is required for the CPU-only implementation. No possibility to comment out the GPU stuff completely? I'd just limit it to the CPU implementation and then save out a result to an OBJ and drag and drop it into Clara.io or the ThreeJS editor and see if it loads. I wouldn't even worry about display parts to start or porting the viewer, unless it was no work. We might be able to help with a wrapper-API in January if you wanted to share in a PR or something like that. |
On Thu, Dec 19, 2013 at 8:16 AM, Ben Houston [email protected]:
It's 4MB (700k gzipped) for a debug build and I'm not sure if that's
I disabled GPU & OpenGL 4+ support (via CMake), but my thinking is that Build hackery is fine, but I want to make as few source code changes as I'd just limit it to the CPU implementation and then save out a result to
Yeah, I could construct an easier test, but want to see simpleCpu work...
That would be awesome. Also, I think helping out with the web worker My time to work on this is super limited, so help would be great. Jeremy |
I had a look through the code and GLEW is only used if you want to run the viewer. :) I think few people want a non ThreeJS viewer these days, so I wouldn't spend too much time on it. Need to just save out as an OBJ. :) |
ThreeJS is crazy easy to use for simple interactive viewers. One could modify one of these examples and just convert to the standard ThreeJS mesh / line format for viewing: |
I agree (and I love three.js), but to run a three.js viewer right now, I would also need the OpenSubdiv binding/wrapper to JavaScript, so it's actually easier to just get simpleCpu demo working. But yeah, the glew issue is secondary, I'll put it aside for the time being. |
So I ended up going the minimal route and making a javascript binding that just takes an OBJ string, something like this: var subdiv = OsdUtil.GetSubdiv(objString, refinementLevel) and it works! I'll try to put something together that I can share over the break. |
This pull request has the basic build support, but does not include the JavaScript bindings (which are still IP): |
Duplicate of #250 Closing for now. |
I would like to support OpenSubDiv in our web-based 3D modelling package http://clara.io We already have Catmull-Clark subdivision support but it isn't anywhere near the full set ( https://www.youtube.com/watch?v=Bn8bnE-tlyA ).
To fully support all the features of OpenSubDiv, I would like to have a JavaScript implementation of OpenSubDiv.
I did some Google searches and so far no one seems to have ported OpenSubDiv to JavaScript, or at least I couldn't find anything.
What is the minimal about of code that would need to be ported to JavaScript to have compatibility? Should one port the C++ core or try to port the shader code to WebGL GLSL? Or has any one tried emScripten (the C++ to JavaScript compiler) on OpenSubDiv?
Does this (getting OpenSubDiv in JavaScript) interest anyone else?
PS. Thanks for making this public, this is an awesome contribution to the community. Hopefully we can contribute a bit to it. :)
The text was updated successfully, but these errors were encountered: