chilipeppr requirejs variant problems with latest three.js:

chilipeppr requirejs variant problems with latest three.js:

I am currently undertaking maintenance on widget-3dviewer to bring in my raspberry pi optimizations as config items and I decided to tackle the port to the latest three.js. However, due to the removal of global scope, its not playing nice with require.js. It seems as though the modified require.js for chilipeppr is older than the latest require.js and im wondering if the deps and exports shims just dont work correctly. I have zero prior experience with require.js, so I dont know if im barking up the wrong tree or not.

I think you are barking up the correct tree. I tried a few weeks back and found same problem. It felt like it was going to be a decent amount of work.

I dont mind taking this head on. What I may do is put together a test for require.js vanilla and three.js, just to ensure all the components we need work correctly in a vanilla situation. Ill then pull down the cprequire code and try sync it up.

I found a stub, it works… Will knock out the updates tonight

That’s good news

Hey John, ive only tested this in the widget viewer, not in the workspace so Im not going to create a pull request just yet. But please take a look at https://github.com/dchote/widget-3dviewer/commit/8fc16857889749e6df9aeb19792e803e1ad56dc8

Moved everything over to the latest three.js and transitioned deprecated interfaces to the new ones, also replaced the shadow plane.

The key thing in the workspace is that 5 other widgets reference http://three.js and they all need to point to the same one for this to work. Auto level, touch plate, super touch plate, eagle board widgets.

yeah, which is why I haven’t tested it all yet :slight_smile: Im going to review and possibly rework the fps stuff (since thats really about animation speed, more than actual rendering fps). And im going to investigate dynamically scaling fps based off latency, if the browser is bogged down, scale it back, and potentially enable a mode that only renders while moving the scene or loading a new file…

That sounds amazing.

running big jobs on the pi, and watching what falls apart, im pretty confident at this point that we can make chilipeppr run FANTASTIC on an rpi3 with some minor optimizations. There are only 2 or 3 situations that ive found can overload the pi, and its in the initial loading of the gcode and then when running a large job with animations going (700kb gcode file).

Latest and greatest three.js and modules.
missing/deleted image from Google+

@jlauer Is there a better way to include external files, I know you filter a lot through your host. For my dev im using a github raw file cdn proxy thing, but… its not a good long term solution for production.

A file could be placed on the Google App Engine host as a long term solution, but what I’ve been doing is just putting it in the Github repo and then using ChiliPeppr’s http://chilipeppr.com/geturl?url=… feature because it’s way easier to do and is a reasonably long term solution because what it does is cache the URL and not go back and even check once it’s cached. The only way to get it to go back and re-retrieve is if it sees ?forcerefresh=true so it’s almost like a way of uploading to ChiliPeppr’s servers

@jlauer I’ll update the paths to use geturl.

I just took a look at your changes at https://github.com/dchote/widget-3dviewer/commit/8fc16857889749e6df9aeb19792e803e1ad56dc8 and I think it looks amazing. You had to change a lot of stuff. Indeed that BoxHelper stuff changed in newer versions, but it looks like you found everywhere it had to get updated. I love that you added the antialiasing on/off feature. The shadow working again is great too. When I had to use those shaders it created a lot of problems on different platforms. Your approach seems standard and thus should work everywhere. Glad you deleted lots of commented out code too.

I think your hack to get THREE as a global is perfectly fine. I would move that define closer to the cpdefine call as that’s core code. The cprequire_test code gets removed so I always try to keep it near the top as it disappears in production. Did you try doing the define call inside the cpdefine just to keep the core code all inside the cpdefine module?

It does look like you don’t need to load ThreeBufferGeometryUtils anymore? Is that because they finally included it in the core Three.js library? This was the library they finally added around r70 that I moved to for more efficient memory on the 3D viewer and faster rendering times.

@jlauer Thanks! Yeah, a LOT has been moved to core, which is sensible for long term maintainability. Ill attempt to move the define around, I dont think it’ll work inside the cpdefine, because that method is called after the includes all occur, the THREE undefined issue occurs within those includes.

Im going to dig in to the animation timer and fps stuff tonight (kids permitting). I think we can very sensibly have the ability to disable animation, but still render new files as loaded, and provide drawing for scene movement. I need to look at the codepath more (in terms of pubsub) and see if maybe we can render updates on toolhead moving to the next gcode line, without tweening.

Yeah, the tweening has always had a couple issues. 1) the tweening does not take into account feed rate so it’s just a set speed based on 1x, 10x, etc that user chooses. I always wanted to take in feed rate, which would likely require parsing such that each line has a feed rate attached to it based on parsing. 2) it never followed G2/G3 arcs rather just did start/end point moves. the g2 arc rendering is in the three.js data but it would have to get taken into account in the tweening. every couple months somebody posts on why the simulator doesn’t follow arcs. so it would be nice to get there.

On the animation, there’s a method called wakeAnimate() and so even if the viewer is disabled, that method could just get called on drag/drop so that the 3d viewer renders, but then goes back to sleep on it’s own a few seconds later.

BTW, i do call the browser method that takes into account CPU load to try to give you more or less callbacks to render animations. i think it’s called requestAnimationFrame() and that’s why you get some confusing operations in my rendering code to get that callback sequence working better, but then i added all that code to try to reduce frame rate even with requestAnimationFrame() in the mix. That was a hard part of the code to get it to be clean. I do get worried though that sometimes I end up with a dual or triple loop of callbacks and overly animate.

Ive still got a long way to go, but im exploring alternative ways to funnel the animate() logic, moving towards a dynamic fps scaling system: https://github.com/dchote/widget-3dviewer/commit/e762b222001b969cb3f7dd5fa02103e8ddf38e3a

Wow, that is a lot of stuff you’ve changed/worked on. Looks pretty good though. One thing to keep in mind is I would sleep the animation after about 5 or 10 seconds if there was no movement. This was pretty key to not have your browser sitting there chewing through CPU. Most of the Three.js examples on http://threejs.org keep chewing up CPU even in the background, so I put a lot of effort into that. Not sure if you were aware of that approach, or if perhaps Three.js has a newer approach that does this automatically. Or if the animationRequestFrame() method is better now that it solves that inherently.

@jlauer as it stands right now, it doesn’t do anything unless it’s playing or moving. I need to change the inspect logic higher up, as that seems to still be pretty intensive, even with the animation delay.