Diorama, Myriorama, Unlimited detail-orama

Let me tell  in plain words  the explanation by  JX about how a UD algorithm might work (is not just an idea, is supported by proof, experiments, go and see this post).

It is too funny! Is the computer version of a diorama. Is an unlimited-detail-orama.

Before giving the zest of the explanation of JX, let’s thinks: do you ever saw a totally artificial construction which, when you look at it, it tricks your mind to believe you look at an actual, vast piece of landscape, full of infinite detail? Yes, right? This is a serious thing, actually, it poses a lot of questions about how much can be  compressed the 3D visual experience of a mind boggling  huge database of 3D points.

Indeed, JX explains that his UD type algorithm has two parts:

  • indexing: start with a database of 3D points, like a laser scan. Then, produce another database of cubemaps centered in a net of equally spaced “centerpoints” which cover the 3D scene. The cubemaps are done at screen resolution, obtained as a projection of the scene on a reasonably small cube centered at the centerpoint. You may keep these cubemaps in various ways, one of these is by linking the centerpoint with the visible 3D points. Compress (several techniques suggested).   For this part of the algorithm there is no time constraint, it is done before the real-time rendering part.
  • real-time rendering: input where the camera is, get only the points seen from closest  centerpoint, get the cubemap, improve it by using previous cubemaps and/or neighbouring cubemaps. Take care about filling holes which appear when you change the point of view.

Now, let me show you this has been done before, in the meatspace.  And even more, like animation! Go and read this, is too funny:

  • The Daguerre Dioramas. Here’s (actually an improved version of) your cubemap JX: (image taken from the linked wiki page)


  • But maybe you don’t work in the geospatial industry and you don’t have render farms and huge data available. Then you may use a Myriorama, with palm trees, gravel, statues, themselves rendered as dioramas. (image taken from the linked wiki page)


  • Would you like to do animation? Here is it, look at the nice choo-choo train (polygon-rendered, at a a scale)


(image taken from this wiki page)

Please, JX, correct me if I am wrong.

17 thoughts on “Diorama, Myriorama, Unlimited detail-orama”

    1. John, it’s not just ordinary cubemaps from flat images, each point also has depth (it may be one more layer in the image) so they are projected like 3D points. Each cubemap have 6*(Size^2) such points or less, but not more.
      You may also think of it as about laser scan frames. Here is nice picture of laser scan frame from real life (rendered from shifted point of view): http://www.naismithmarine.com/uploads/Multibeam-Laser_Scan.jpg
      When virtual camera stays inside frame’s center everything look solid as it was cubemap. When camera moves, everything moves correctly as it should be in 3D, but you see holes when point of view is shifted far from “laser head”. To fill the holes one can combine few such frames taken from different positions.
      That is, just set of tricks, not very impressive and consumes much disk space, but really removes dependency from scene size and complexity and allows streaming of data (UD also has this I’d say noteworthy feature).

  1. Re: John#1. Yes, a skymap may be like a diorama, but the cubemaps JX is talking about are near your viewpoint and they are actualized as you “walk” in the scene. The thing is that the indexing step allows you to do real-time rendering of these cubemaps, and not of the whole huge scene, which would be impossible.

  2. You may be onto something with this cube map idea. I suppose it’s like googles street view but with more photographs. If you know the relationship between pixels in adjacent ‘boxes’ you can interpolate their positions when moving. Unlike photos, you know everything about the world, and can gather correlations between many things.

      1. Sorry I accidentally replied to your post, rather than start a new comment.
        I used to think Euclideon’s work was a direct copy ofDonald J. Meaghers patent from the 80s. It’s the only thing that has come close to actually be doable – it’s a low detail octree, with quadtree screen splatting being done within that 2D projected cube. Someone’s done a demo using it here:

        * It also has the same errors down the edge of the screen, which clinched it for me.

  3. I don’t like the attitude like “Euclideon created something new that nobody before thought of”. If Euclideon solved something and do everything to hide their problems we can assume this is far from a perfect solution. Maybe it’s better to think of something totally new than a bad copy of their work. Pregenerate and cache stuff kill flexibility.

    1. No, I don’t agree with you. Bruce Dell tried repeatedly to show his work, only to be rejected because he is not in the mainstream. What about all the guys who dismissed UD?

      But yes, it is indeed better to try to find something new. And, yes, although I understand his point of view, I wish he gets in the open and show everybody his solution.

  4. chorasimilarity :
    Dave, see this post, this is not UD, from several points of view, explained by JX in this comment.

    OK thanks, I’m new to this blog, and it’s very interesting. I can’t help thinking about the messy side edges Euclideon are getting on their early demos though. I realise correlation doesn’t equal causation but it has intriguing similarities to Meagher’s screen edge errors.
    Maybe they can decompress the data in LOD ranges from the disk in, say, ‘meter’ cubed size chunks?
    You can play with some of Donald’s rendering demos at http://www.octree.com, and some models show the error on the sides.

    1. Dave, my guess is that the UD algorithm uses a combination of JX approach via the cubemap and octrees. But the octrees are just a step in the initial processing of the new database. I guess it counts as a solution of the ray shooting problem, but without shooting rays. At some point you use octrees, but after that you reorganize the database differently, such that it can be used very fast in order to give you JX’s cubemap. I shall leave for the moment this as the puzzle 2D UD because I hope that some clever hacker like JX comes with an implementation better than I could do myself.

      Anyway, it is still beyond my understanding why the idea of “unlimited detail” was dismissed without discussions when in fact it is a very sober problem: give a solution of the ray shooting problem which allows to exploit the database (cleverly constructed by the solution) in O(K log N) time, where K is the number of pixels on the screen and N is the number of 3D points represented in the database. AFAIK there are solutions which are polynomial in N. Instead, there were lots of discussions about the voice of Bruce Dell, the design of the images from the presentation and other inessential stuff.

      1. A lot of people just couldn’t comprehend there is a way a doing something that they didn’t know already, and dismiss it. It’s really just typical human behaviour. ; )
        It got some viscous attacks, that’s for sure.

  5. Re: Stephen. Now it dawned on me that there is something here related to one of your old comments here, cite: “In plain terms: Consider a pair of computers that are each generating a simulated landscape and that a user on each computer can alter the landscape (from their respective points of view) in some way. How do we generate new landscape that show the changes that are done by each user so that the picture that each user could see of the landscape remains consistent with the old landscape.
    MMORP games such as World of Warcraft do this, but they do not do so in a way that is continuous. I am looking for a continuous version of the updating of the landscape for the multiple users.”

    I see a relation here, namely: one of the advantages of UD, according to Bruce Dell, is that it offers the possibility to store the world (i.e. the UD formatted database) in one place such that it can be queried by many users from a network in real time. Why is this possible? Because, due to the UD format, it becomes easy to send to each user only the tiny amount of data which is necessary to construct it’s respective cubemap (tiny compared to the hugeness of the whole world database). Moreover, suppose that each user modifies locally the world, then it is not impossible to imagine that the modifications, being local, can be sent back to the database. The only problem comes with the modifications which affect several users sharing a part of the world simultaneously accessible to their respective cubemaps. But this is a local problem, which could be handled by local algorithms, the enormity of the world is never a problem. Conclusion: as long as there is a limit on the number of “players” which share common parts of the world, the problem of maintaining the database is local.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s