I love this. I think "pseudo-2D" might be more accurate.
Zdog – Pseudo-3D JavaScript engine for Canvas and SVG
41–50 of 96 posts
Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG
#42Earlier 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…
In conventional 3D graphics each pixel is painted in 3D and a depth test applied. Here, 2D shapes are ordered discretely to create a 3D effect. Instead of the per-pixel z-fighting you conventionally see in 3D graphics, here we see entire shapes cross each other. This method cannot correctly paint intersecting, or cyclically occluding shapes (without breaking them into smaller components). I think "pseudo" could refer…
A depth buffer is something that you find common nowadays, especially with the GPUs providing it essentially for free, but again it is not what makes 3D graphics and a lot of otherwise full 3D polygonal games were made without it nor it is necessary to create 3D graphics. With other approaches to 3D rendering you do not even need a depth buffer to get correct results for penetrating objects (e.g. classic raytracing).
What is happening here is called "painter's algorithm" and was a very common approach for realtime graphics before depth buffers became hardware accelerated. Actually it is still often used even today for transparencies since those often cannot be rendered in arbitrary order and you need to depth sort them. One common approach to solve these issues - both then and now - is to subdivide/preprocess geometry so that wrong overlaps are not or rarely happening.
Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG
#43Pop this on product hunt, you'll get your first few thousand users in no time. > Zdog is directly inspired by Dogz, a virtual pet game by P.F. Magic released in 1995. It used flat 2D circle sprites to render the Dogz’ models, but in a 3D scene. See Dogz playthrough video here. Dogz were fully animated in real time, running, flopping, scratching (on Windows 3.1!). It was remarkable. The new repeating the old. Love whe…
When I was looking at this and seeing the z-sorting pop I was instantly reminded of Catz, a similar product. Cool to see that was the inspiration
Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG
#44Does it work on IE11?
Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG
#45Earlier quoted context omitted.
In conventional 3D graphics each pixel is painted in 3D and a depth test applied. Here, 2D shapes are ordered discretely to create a 3D effect. Instead of the per-pixel z-fighting you conventionally see in 3D graphics, here we see entire shapes cross each other. This method cannot correctly paint intersecting, or cyclically occluding shapes (without breaking them into smaller components). I think "pseudo" could refer…
A depth buffer is something that you find common nowadays, especially with the GPUs providing it essentially for free, but again it is not what makes 3D graphics and a lot of otherwise full 3D polygonal games were made without it nor it is necessary to create 3D graphics. With other approaches to 3D rendering you do not even need a depth buffer to get correct results for penetrating objects (e.g. classic raytracing).…
Indeed. I avoided the term depth buffer for this reason. A depth test is still necessary on a per-pixel basis for a correct solution to the visibility problem in the general case - even if that's done by raytracing or some other method.
The painters algorithm is not a general solution because it cannot handle cyclical occlusion: https://en.wikipedia.org/wiki/Painter's_algorithm#/media/Fil... Its limitations constrain the geometry which may be correctly rendered.
Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG
#46Super-crude STL file reader I whipped up in 10 minutes: https://codepen.io/dheera/pen/zQJBrx
nice stuff man!
Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG
#47Very clean and fast. The API also looks good, I like hierarchical translation and scaling. Is there anything preventing animation?
Seems like there shouldn't be since the examples are interactive (can rotate the move the shapes in 3D space with the mouse), but perhaps animation is a DIY exercise on top of this library
Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG
#48Does it work on IE11?
Just tried it. No it doesn't.
Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG
#49Awesome, congratulations to the creator! I started doing something a little similar, to render pseudo 3d shapes to canvas, here is an example[0]. Try clicking on the page and moving the mouse.
Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG
#50Earlier quoted context omitted.
A depth buffer is something that you find common nowadays, especially with the GPUs providing it essentially for free, but again it is not what makes 3D graphics and a lot of otherwise full 3D polygonal games were made without it nor it is necessary to create 3D graphics. With other approaches to 3D rendering you do not even need a depth buffer to get correct results for penetrating objects (e.g. classic raytracing).…
Indeed. I avoided the term depth buffer for this reason. A depth test is still necessary on a per-pixel basis for a correct solution to the visibility problem in the general case - even if that's done by raytracing or some other method. The painters algorithm is not a general solution because it cannot handle cyclical occlusion: https://en.wikipedia.org/wiki/Painter's_algorithm#/media/Fil... Its limitations constrain…
My point above is that to call something 3D graphics does not depend on having per-pixel correct visibility and painter's algorithm (and others) is a valid method to render 3D graphics and was for many years. Applications using it either accepted the limitation (many games did that) or tried to overcome it by preprocessing the geometry to create clusters that are unlikely to overlap or by performing subdivision on the projected polygons.