Skip to main content
New Participant
December 17, 2013

Oculus + unlimited detail (Euclideon)

I'm not a developer, just a gaming and VR enthusiast. I was wondering if anyone thought of or is working on using Euclideon's Unlimited Detail technology to make an absolutely EPIC VR experience yet? If you haven't heard of Euclideon, here is their official site, it is truly incredible, and it's potential could be more fully appreciated and realized with the Oculus.

http://www.euclideon.com/

Euclideon's unlimited detail technology does exactly that. It allows the use of unlimited point cloud data in place of polygons for rendering graphical software. Sounds impossible, but they claim it works due to a google-like search algorithm that is able to find and send to your systems ram, only one point of cloud data for every pixel of your monitor. In this way the processor requirements to render any scene no matter how graphically detailed, stays exactly the same, and manageable. Whats more, the requirements are so low, even a basic laptop can produce graphics 100,000 times more detailed than even the most advanced polygon-based game on the market today. It seems to me, that due to this fact, it should help the oculus meet it's demanding latency requirements far better than polygon-based graphics, AND it will look about 100,000 times cooler... but dont take my word for it, do your own research on this.

Euclideon has received a lot of flak and harassment from the tech community doubting their claims, but as you can see from their site, they have their act together, and make a very convincing case.

someone with the skills, MAKE IT HAPPEN please!!! Oculus + Euclideon = EPIC WIN and the future of simulation technology.

    86 replies

    Participant
    January 16, 2014
    This could be interesting , but a few years from now i think
    Up and Coming
    January 16, 2014
    I'm still of the opinion that Euclideons plans of ever developing a games engine was a scam. But since people are talking about it doing animation, here's a video in which they show a tiny bit of what they have been able to do with animation.

    I never doubted that they could do animation. The question is, if they could do animation well. Well enough for something consumer viable. Their sudden shift to geospacial stuff instead of games to me says that if they weren't scamming all along, then doing animation, like a lot of things needed from a engine, is no where near as easy as they liked to pretend it was. From the start they have had a problem of talking big and making grandiose claims of what they can do now and could do in the future, and never being able to back up either. For their future claims at least, they just overestimate their abilities and act like solving the complicated issues are going to be easy.

    To put things into perspective, they are about 1 1/2 years overdue on a demo they promised.

    Jump to 32:33 for the animation demo.

    Project: Ocarina - The Legend of Zelda, Ocarina of Time in VR @DarkAkuma_ - Twitter http://darkakuma.z-net.us/ - My Blog http://www.z-net.us/ - SNES Online Gaming
    Up and Coming
    January 17, 2014
    "Sheshbazzar" wrote:
    D. J. Meagher does animation from of old: http://octree.com/4D/


    -.-

    Seriously? Frame-based animation? That's your comeback?

    The last mobile game I worked on blended up to fifteen separate animations at a time on a single character. I know because I wrote the animation blender. You need that if you want a guy to smoothly segue from reloading in a crouching strafe into aiming in a forward sprint.

    But that's OK: I guess we just need a point cloud for every possible ~10-way-combination of times and weights of ~200 animations. For every different character model. I'd work out how much storage that would take but you might need to lend me some numbers.

    Dell did animation.
    Euclideon does animation.


    No, they don't. The video DarkAkuma kindly linked shows multiple point clouds rendered from different camera positions composited to the same screen. That is not skinning, animation or deformation. In particular it is very much not parts of a point cloud moving or turning, which means you need a separate point cloud pass for every object, which trashes the 'one search per pixel' efficiency of the basic algorithm. And I can guarantee you / and * were involved in the lighting calculations.
    Participant
    January 19, 2014
    For prior art's sake, a novel volume rendering technique: consider a view pyramid & an octree cube in it. 0) narrow the pyramid about the cube, 1) consider the rectangle that is its intersection with the view plane: if rectangle not occluded then if rectangle small enough (leaf cubes' rectangles are considered small enough) then output it in the cube's color. Otherwise proceed, with the narrowed pyramid, to the octree's children, in front-to-back fashion.

    I have an implementation free from /, * or floats. It is remarkably short & rather fast. When a satisfactory state is reached I will publish it here: http://goo.gl/UXCd5J. Note that this is literally orthogonal to both casting things (ray, cone etc.) & splatting.
    Up and Coming
    January 20, 2014
    "Sheshbazzar" wrote:
    I have an implementation free from /, * or floats.


    That's great, but what are you planning to do with this colour once you've found it?

    In all but the very simplest matte-diffuse surfaces (which are rarely used because almost nothing in real life is perfectly matte-diffuse) under perfectly static lighting, the actual colour of a rendered pixel is a function of surface normal, light and camera position, with surface information providing further parameters. Unless you retrieve a colour, specular value and surface normal AND know the 3D coordinates of the pixel, you won't be able to do even basic stuff like shiny surfaces.

    Many if not most of a modern GPU's floating point operations are spent AFTER transformation, rasterisation and texture fetch, ie AFTER the surface properties of a screen pixel have been retrieved. Euclideon/your algorithm gets you to that same point: knowing the surface properties of a screen pixel. Most of the mathematical heavy-lifting is still to be done.
    Up and Coming
    April 4, 2014
    I don't know if this has been posted before, but these guys nailed it..
    There's a video a bit farther down the page, I find this impressive.


    http://chorasimilarity.wordpress.com/tag/euclideon/

    http://vimeo.com/69741964

    http://bcmpinc.wordpress.com/

    The source is on github.

    It has nothing to do with fancy BWT sorting and stuff.

    Oh I see that gm posted this before, funny that there are not much comments on this...
    Up and Coming
    April 4, 2014
    for gaming experiences this would not be ideal in my opinion. this would take the art out of creating actual virtual world environments. and for me a really good gaming experience is and should always be a work of art over technology.

    but with that said this technology combined with the new 3D scanning technology i saw demoed on a smart phone not to long ago has the potential to revolutionize google earth and street view type user experiences as we know it. I would invest in if i had the money. honestly google would probably jump on this in a heart beat if it hit critical mass just to incorporate this into their current products.

    still would have to wait for the VR headsets and 3D scanning technology to become ubiquitous though...
    Up and Coming
    April 4, 2014
    hmmm on second thought not so sure this is legit after reading some of the other users posts.... had me going for a second. but i suppose if the code is really that interesting...

    by 'invest' i really meant buy-out their company then fire everyone, hire my own team to reverse engineer their product and make it open source if google doesn't buy it

    hypothetically speaking of course and only just because i could :P
    Up and Coming
    April 4, 2014
    UNLIMITED DETAIL IS A SORTING ALGORITHM:
    http://chorasimilarity.wordpress.com/2013/02/28/unlimited-detail-is-a-sorting-algorithm/

    BWT (which I independently invented using different terminology before discovering BWT existed long before my recreation of it) indexing is also a sorting algorithm, and BWT (instantaneous) lookup is a search algorithm. Bruce Dell said euclideon uses a search algorithm, making me think my intimate knowledge of BWT would easily fit that usage scenario.

    This also matches what I said in PMs about this in the past. Nothing new to see here. No reason to be upset that I withheld important details from friends. I shared everything that I could think of while typing my PMs, that could fit into a PM format...

    I am certain I can do this given enough time. But like others say, it is not appropriate for dynamic lighting such as you get with the rocket launcher in Quake. But still, it would be awesome to explore (pre-baked lighting) virtual worlds using this rendering engine. And from the RedFrame demo, we know how great pre-baked lighting can look, making the whole screendoor effect pretty much a non-issue on the DK1. Lots of rendering time to bake the lighting effects, and a lot more to sort the BWT index (but I use super-efficient induced BWT sorting in my code, which is MUCH faster than other sorts)...

    You need a large hard drive (or SSD, or internet cloud) to store the pre-baked and sorted BWT point-cloud color data, with a good caching algorithm to preload data just before it is needed. Obvious stuff (for aspies at least).
    This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
    Up and Coming
    April 4, 2014
    There are other sort algorithms...

    Conveniently you do not have to prove yourself. you must be right tho... because you are aspie......
    I am sorry but unless you can prove that indexing 2 million points and accessing them below 30ms I don't approve .

    Btw the renderer is a cubemap with a sparse octree according to the guy who did it.

    The renderer is the piece that interested me the most. Data storage and retrieval is secondary.

    Let's talk bwt, because you never explain how you store sort and compress by pm.

    I know that bwt sort can compress efficiently. I see that bwt could retrieve fast if you keep a state with delta to neighbor blocks. I do not see how you can march in 3d using bwt.