Thanks a lot! Tho "example code below... function has not been heavily tested as yet" seems to be the predominant term, where-ever I look. Will try it out. You know, one of those days... things don't work, so you start rewriting the underlying layers... at some point you then have to rewrite the OS or something. So I had this idea to use copperlicht as a renderer, but failed to implement collision cam vs mesh in code, so after many hours I thought it's easier to implement collision by my own, which was where the non-working RIT function came into play.
At some point I intended to write my own, to invent the mother of all RITs (slight megalomania phase): if watched from 3 sides, the ray must intersect with some of the edges on all 3 views, or alternatively have both, start end end ray point inside the 2D view triangle. I had a working 2D line-intersect-line code, so I needed a 2D point in triangle code, which again duckduckgo hid any good info from me, so I brainstormed and realized: if the point is inside, then all 3 lines from the point to the 3 corners of the triangle will NOT intersect with any of the triangle edges. Otherwise the point is outside (ignore intersection when intersection point is equal triangle corner). Long story short, nice theory, isn't it? However, it just didn't work for some mysterious reason. The ghost of Elvis in the CPU or something. So after countless hours I run coppercube, used it to convert my mesh to a ccb webgl level, with collision preset, et voila! I got collision now. Still, I'd love to be able to do that in copperlicht.js without coppercube as a converter, but the docs they ehrm - feature an underpressure effect.
That said, one day somebody like me or you, should really look into developing a converter for something like Blitz3DLite to WebGL, be it copperlicht, babylon or one of the few others. Cause I have yet to find a system with a learning curve so NOT steep and prototyping speed so fast as Blitz3D. (That is, under normal circumstances AKA "Elvis left the CPU"-state)