Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Notch on Euclideon: It's a scam

notch.tumblr.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Notch on Euclideon: It's a scam

#41

Post by Klinky »

pgroves wrote: post #33

Why is the product considered worthless if it can't do animation yet? The demo clearly walked through examples of inanimate artifacts that are currently rendered as bitmaps on big polygons that could be greatly improved, today, by the technology in the demo. Backgrounds, cityscapes in the distance, the trunk of a tree, etc. The argument that it's a scam if it can't render grass blowing in the wind is ridiculous.

Because they are claiming an increase of detail by a factor of 100,000, while the demo barely showed anything close to a detail increase by a factor of 1.

Trees & rocks are often animated in modern games, so animation is important. Additionally there is no point using a heavy duty voxel engine to render background landscapes that no one will visit in the game, especially if it's going to take gobs of RAM & CPU time to do it.

Hardware tessellation can already greatly increase surface detail, is already available in modern hardware & has better looking demos.

http://www.youtube.com/watch?v=4G9anRoYGko

http://www.youtube.com/watch?v=gT_45RFFTx8

http://www.youtube.com/watch?v=0HWZKGZcKoA

Re: Notch on Euclideon: It's a scam

#42

Post by cheald »

superfx wrote: post #38
interrupt wrote: post #37

Earlier quoted context omitted.

Anyone who's watched that demo has noticed exactly what he said, that their demo is basically a 2D tilemap of a few repeated 3D objects, most likely to make the memory requirements of storing voxels at that level of detail feasible.

If I recall in the demo, they kept on referring to procedural generation, and so perhaps they have a few tricks up their sleeve for generating content (trees being an obvious example) that would be varied yet take up little memory.

Procedurally generated assets take very little storage. They still take just as much memory to actually put into the scene graph and render.

Re: Notch on Euclideon: It's a scam

#43

Post by tzs »

eridius wrote: post #32
bugsy wrote: post #15

The use of the word "scam" is really inaccurate based on the rest of the post. He agrees that the demo is real, and calls it a scam since others are working on similar things and they are trying to get funding. Neither others working on the same thing nor trying to get funding make something a scam. It would be a scam if they weren't really rendering what they say they are in real time, but Notch doesn't claim that.

He calls it a scam because they're making hyperbolic claims, very carefully ignoring any mention of any of the drawbacks to this technology, and pretending that it's all brand new technology when it's actually been done before. And they're doing this to make money via investors. It would be _fake_ if they weren't rendering it in real time. He didn't call it fake. He called it a scam.

How do we know it has been done before? All I've seen so far are people guessing how it might be done--and then analyzing their own guesses to find they are inadequate, and then somehow concluding that means that nobody could do it.

Re: Notch on Euclideon: It's a scam

#44

Post by mambodog »

The guy behind Atomontage has stated that he's got his engine averaging less than one bit per voxel (he estimates 753 bits or less per 1000 voxels)[1] by applying a variety of compression mechanisms[2], so at least that part of Notch's assessment can be disregarded out of hand.

EDIT: Taking a step back, remember that with an octree, contiguous areas require less tree depth to fully describe them, so open empty space (sky) and consistently filled space (uniform material underground) require much less data. This of course creates practical limitations in addition to the claimed maximums of what the engine can achieve (so art budgets aren't going anywhere anytime soon) but I think calling it a "scam" is a bit much.

[1] http://www.youtube.com/watch?v=1sfWYUgxGBE

[2] http://www.atomontage.com/?id=tech_overv

Re: Notch on Euclideon: It's a scam

#45

Post by Xk »

mambodog wrote: post #44

The guy behind Atomontage has stated that he's got his engine averaging less than one bit per voxel (he estimates 753 bits or less per 1000 voxels)[1] by applying a variety of compression mechanisms[2], so at least that part of Notch's assessment can be disregarded out of hand. EDIT: Taking a step back, remember that with an octree, contiguous areas require less tree depth to fully describe them, so open empty space…

Fine. Assume it's one bit per voxel.

512 petabits = 2 petabytes.

So only 2 petabytes of data. I'd like to see the server that processed those 2 petabytes.

Notch also points out that even still, 8m is quite a small height. Take it to 16m and now you need 4 petabytes of space.

Re: Notch on Euclideon: It's a scam

#46

Post by wlievens »

cheald wrote: post #42
superfx wrote: post #38

Earlier quoted context omitted.

If I recall in the demo, they kept on referring to procedural generation, and so perhaps they have a few tricks up their sleeve for generating content (trees being an obvious example) that would be varied yet take up little memory.

Procedurally generated assets take very little storage . They still take just as much memory to actually put into the scene graph and render.

Not if your assets are functional, such as a procedurally generated heightmap. Then they take up next to no memory.

But you can't do that efficiently for a tree, I think.

Re: Notch on Euclideon: It's a scam

#47

Post by skyfex »

cheald wrote: post #42
superfx wrote: post #38

Earlier quoted context omitted.

If I recall in the demo, they kept on referring to procedural generation, and so perhaps they have a few tricks up their sleeve for generating content (trees being an obvious example) that would be varied yet take up little memory.

Procedurally generated assets take very little storage . They still take just as much memory to actually put into the scene graph and render.

Not with ray casting of sparse voxel octrees, which is probably what they're doing. Depending on how the procedural generation work, you only need to generate that which you render.

Re: Notch on Euclideon: It's a scam

#48

Post by mrhyperpenguin »

Am I the only one that agrees with Notch and does think that this "unlimited detail" technology is a scam?

Euclideon is asking for money to develop "new" technology that in reality has been done before and does not have any advantages over a polygon based engine. Everything in their demos can be done (if not better) using a polygon based engine and modern GPUs.

Seriously, just watching one of the videos by Euclideon makes me feel like I'm watching late night tv advertisments. If their tech is as "ground breaking" as they claim, surely they wouldn't need to do as much convincing as they currently do in their videos.

Re: Notch on Euclideon: It's a scam

#50

Post by Robin_Message »

Xk wrote: post #45
mambodog wrote: post #44

The guy behind Atomontage has stated that he's got his engine averaging less than one bit per voxel (he estimates 753 bits or less per 1000 voxels)[1] by applying a variety of compression mechanisms[2], so at least that part of Notch's assessment can be disregarded out of hand. EDIT: Taking a step back, remember that with an octree, contiguous areas require less tree depth to fully describe them, so open empty space…

Fine. Assume it's one bit per voxel. 512 petabits = 2 petabytes. So only 2 petabytes of data. I'd like to see the server that processed those 2 petabytes. Notch also points out that even still, 8m is quite a small height. Take it to 16m and now you need 4 petabytes of space.

Nope, more like 2 petabytes plus 1 bit. Because almost all of that new top 8m is the same atom (empty air), if they are using an octree to store the voxels, then it would take 1 extra bit to store an empty top 8m. Obviously if there are things in the top 8m, it will take more space, but only for the things that are there.
Post reply on HN