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

Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

zzz.dog

Post reply on HN
Print view View original

61–70 of 96 posts

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#61

Post by Wowfunhappy »

ClassyJacket wrote: post #11
overgard wrote: post #6

I notice that there are some issues with depth sorting (which I guess would be expected). It'd be complicated, but one way you could do the same effect without that issue is to use signed distance fields in a shader: https://www.iquilezles.org/www/articles/distfunctions/distfu... (Demo at the bottom of the page)

I wonder if some sort of progressive dither or fade is practical to implement and fast enough (and visually useful)? If I wasn't at work right now I would have a look at the code. I have some experience with Canvas rendering but, like this, just in straightforward layers. I don't think a dither would be practical, a fade might be using a mask and setting the alpha, but you'd still have to detect all the overlap. I'd…

Yeah, if possible, I really think replacing the pop with a fade would help a ton.

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#62

Post by Wowfunhappy »

cr0sh wrote: post #56
erikpukinskis wrote: post #51

Earlier quoted context omitted.

If it helps, think of it as an “actual 3D” scene where objects are laid out in three dimension, but within each bounding box is just a 2D painting of that object. So wherever objects intersect they just act like flat sprites hitting each other. They also have flat (2D) lighting. It’s very similar to a sprite based 3D engine. For other “pseudo-3D” engines see Wolfenstein, or even Super Mario which has “actual 3D” para…

Back in the day it was also referred to as "2.5D" https://en.wikipedia.org/wiki/2.5D Also, the whole sprite thing was used in a lot of Amiga demos in the late-80s-early 90s and was termed "vector bobs": http://www.pouet.net/prod.php?which=3583 http://www.pouet.net/prod.php?which=50417

Sadly, 2.5D has basically lost all its meaning. It's sometimes meant to represent sidescrollers that use 3D polygons, or even fully 3D games that just have a certain camera angle, or any number of other things. :(

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#63

Post by Crinus »

erikpukinskis wrote: post #51
Crinus wrote: post #36

Earlier quoted context omitted.

So does pretty much every single 3D engine that renders to a flat surface, like a monitor. I think it is just a misconception stemming from the 90s (notice the influence of this engine) when anything non-polygonal (and sometimes, non-GPU accelerated, depending on who you asked and how misinformed they were) was considered as "pseudo 3D". But there is nothing pseudo here, if your scene data structures use three dimens…

If it helps, think of it as an “actual 3D” scene where objects are laid out in three dimension, but within each bounding box is just a 2D painting of that object. So wherever objects intersect they just act like flat sprites hitting each other. They also have flat (2D) lighting. It’s very similar to a sprite based 3D engine. For other “pseudo-3D” engines see Wolfenstein, or even Super Mario which has “actual 3D” para…

Heretic is a 3D game, as was Doom, since the world is really 3D: in addition to the 2D vectors making up the walldefs, there is a height component in each sector and entity which adds the third dimension. That some parts of the game (entity-to-entity collision, but not hitscan-to-entity which knows about elevation) ignore the 3rd dimension or that the renderer took advantage of the way the world was represented to speed up wall rendering doesn't really change that the world itself is made up of three dimensions.

Entities being 2D sprites is also irrelevant as they are just billboards and many engines even today use billboards for various reasons (particles, foliage, LOD, etc). They are also placed in 3D space.

Wolfenstein 3D on the other hand, yes, that is a fully 2D game as there is no third dimension outside the implied wall height used during rendering.

I mean, it is really simple, there isn't need to justify some old misconceptions about "2.5D" or whatever that persist due to pop culture: if your graphics data has three dimensions, you are doing 3D graphics.

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#64

Post by Crinus »

roywiggins wrote: post #58
erikpukinskis wrote: post #51

Earlier quoted context omitted.

If it helps, think of it as an “actual 3D” scene where objects are laid out in three dimension, but within each bounding box is just a 2D painting of that object. So wherever objects intersect they just act like flat sprites hitting each other. They also have flat (2D) lighting. It’s very similar to a sprite based 3D engine. For other “pseudo-3D” engines see Wolfenstein, or even Super Mario which has “actual 3D” para…

The original PlayStation didn't even have real 3D texture mapping, it used linear transformations rather than perspective transformations.

This is an element of how rasterization is performed and has no implication on if graphics are 3D or not though. PS1 hardware having no perspective correct texture mapping doesn't make the games that used it "not 3D" - and on the flip side, a side scrolling 2D platformer using a rasterizer capable of perspective correct texture mapping (like any platformer that uses OpenGL or Direct3D to render its worlds as triangles) doesn't make the game use 3D graphics.

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#65

Post by dahart »

overgard wrote: post #6

I notice that there are some issues with depth sorting (which I guess would be expected). It'd be complicated, but one way you could do the same effect without that issue is to use signed distance fields in a shader: https://www.iquilezles.org/www/articles/distfunctions/distfu... (Demo at the bottom of the page)

A signed distance field approach is fundamentally incompatible with this library and it's goals.

Zdog is a vector drawing library, it's resolution independent. When you render to SVG, you can later rasterize that SVG at any resolution. This lets you do things like print at large sizes or high DPI.

Ray marching is a raster (pixel based / resolution dependent) way to render.

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#66

Post by ehsankia »

dahart wrote: post #53
ehsankia wrote: post #2

Is it me, or that `addTo` api feels very strange. Creating new objects with no assignments, with the side effects of adding it to an illustration.

The name is non-standard, but the concept is absolutely normal for a 2D or 3D rendering API. You can think of the ‘addTo’ property as the item’s parent. In 3D APIs this is normally called an instance or transform node, and here the transform is combined with the shape type. Sometimes those are separate things, and they would each have a parent attribute. Some APIs do the assignment the other way, by adding children t…

That makes sense, I'm just not used to constructors having side-effect, though I can imagine wanting to skip the extra step of adding it to the illustration. But wouldn't something like

illustration.addRect({}) look better?

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#67

Post by dahart »

ehsankia wrote: post #66
dahart wrote: post #53

Earlier quoted context omitted.

The name is non-standard, but the concept is absolutely normal for a 2D or 3D rendering API. You can think of the ‘addTo’ property as the item’s parent. In 3D APIs this is normally called an instance or transform node, and here the transform is combined with the shape type. Sometimes those are separate things, and they would each have a parent attribute. Some APIs do the assignment the other way, by adding children t…

That makes sense, I'm just not used to constructors having side-effect, though I can imagine wanting to skip the extra step of adding it to the illustration. But wouldn't something like illustration.addRect({}) look better?

Don't constructors always have side effects? That's the only reason to have them.

I wouldn't think of this as a side-effect though, think of it as a graph property. addTo is setting up a tree structure, the same way you might setup a linked list. Think of the addTo property as a pointer to the parent, rather than a side-effect.

A doubly-linked list has two pointers per node, one for next node and one for previous. A tree node in a scene graph also has two pointers per node, one for parent and one for child. A parent can have multiple children, and so might arrange the children in an array. A child, however, can have only one parent. This makes setting the parent simpler than setting a child, considering corner cases like duplicate children.

Your suggestion is pointing at the addChild() form rather than addParent(). One of the other comments said that kind of call is available in Zdog, so maybe you can just use that instead.

But, I wouldn't use addRect() I would prefer addChild(). A call like addRect() is binding the type of shape and scene graph setup unnecessarily, so you'd have to provide separate calls for each shape type.

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#69

Post by herbcso »

needle0 wrote: post #59

Remembering Dogz and digging through the Wikipedia rabbit hole, I just learned that PF Magic [1], the developer for Dogz/Catz, were also responsible for the SNES 3D fighting game Ballz [2], and its programmer later went on to develop the open-ended experimental adventure game Facade [3]. I knew of the existence of all of them but didn't knew they were all connected! [1]: https://en.wikipedia.org/wiki/PF_Magic [2]: ht…

Why wasn't the last one named Facadez?
Post reply on HN