I'm wondering what would be the best approach to render vector objects (e.g. box, rocket) as if they are drawn with a pencil/crayon? Looking for a dynamic rendering approach like RIA/JS here, not Photoshop etc.
EDIT: perfect would be sth. close to http://bootb.com/en/
Cheers,
stephanos
The subject area that you are looking for is called non-photorealistic rendering. It is currently an active area of research in computer science having many, different branches of study.
I did a quick search for "crayon rendering" and found a paper, "A bidirectional deposition model of wax crayons", that has example images.
You likely will not be able to find an RIA/JS software package for rendering an object as if it was drawn with pencil or crayon (not just using Photoshop filters) without implementing the techniques in research papers yourself. The graphics at the site that you linked to were probably hand-drawn by an artist who used a graphics tablet.
Related
I'm new to glTF and I would have a very basic, and maybe naive, question. Sorry, and thanks for your understanding and your help.
We have a C++ application where we handle geometry primitive entities, like boxes, cones, cylinders, and so forth.
For visualizing the geometry entities we currently use Coin3D, which have corresponding geometry shapes: Box, Cone, ...
We now would like to add a glTF exporter too, and I have started to explore the glTF specs.
I must say, in the official documentation, and on the web, I could not find any support in glTF for basic geometry shapes.
Therefore, my questions are:
is that true, that glTF has no notion of, let's say, a Box, or a Cone? Or did I missed something obvious?
If the answer to 1) is "NO", are there tested/supported/suggested implementations for basic shapes? I have only found some "example" shapes, like the Box here; but I could not find any collection of implementations of basic shapes. Again, did I miss something?
Are there any best practices, or documentation, on how to implement basic geometry shapes in glTF?
The short answer is you're correct, glTF does not currently store basic geometric shapes directly as a box, cone, cylinder, etc. The format is intended to be a runtime delivery format, not an asset interchange format.
As such, the internal data structures within glTF are designed to mimic the raw data that would typically be fed into a GPU using a graphics API such as OpenGL, WebGL, etc. Entire blocks of glTF data can often be pulled off a disk or network and handed over directly to a graphics API for rendering, with minimal pre-processing.
This means that all of your basic shapes must arrive as the GPU expects to find them: triangulated. Even a simple box is made up of twelve triangles, and because the sides don't share normal vectors, the normal "vertex attributes" are different, hence triangles from different sides of the box don't share vertices (again, because the GPU wouldn't accept that as a raw input). The benefit is that a WebGL client doesn't have to think very hard about what to do when it receives a glTF, it can just start cramming data into the graphics pipeline to get things moving.
For a broader overview, the ever-popular glTF - What the Duck diagram is widely considered an excellent starting point, and the glTF Tutorials are a good follow-up to that.
I've been all over the documentation, and there's nothing comprehensive on the subject of graphics. I know it's possible; I've seen freepascal projects that include functional graphics, but haven't been able to replicate the effect myself.
The basics will be sufficient; lines, polygons, possibly text. Any features beyond that (png support, gradients, resizable window, etc) would be appreciated, but unnecessary. The purpose of this question is to find a workable, testable starting point, not to pick out the best libraries for a given purpose.
If it helps, I'm using Lazarus and I have some experience with Pascal as a whole, but I've been away from it since 2007.
simple graphics starting point
Canvas Drawing: https://wiki.lazarus.freepascal.org/Drawing_with_canvas
Using BGRA (open source drawing lib): https://wiki.lazarus.freepascal.org/BGRABitmap
Library list (not complete but a good start):) https://wiki.lazarus.freepascal.org/Graphics_libraries
Also, I'd like to point out that a lot can be found by searching the fpc wiki, or by visiting the forums,
Here's the "Graphics" forum board,
https://forum.lazarus.freepascal.org/index.php/board,39.0.html
As the title says, I'd like to program a 3d game (probably a BattleZone clone), but without the use of an API like OpenGL, DirectX, and the like. At the heart of the matter, I'd just like to learn how to draw basic 3d shapes to the screen and manipulate them. Don't care if it looks like crap. I've used OpenGL to achieve similar ends before, but really didn't learn about these topics.
The problem is, I have no idea where to start. I downloaded the Doom source code, but it's a bit over my head. Although I've programmed a bit, graphical matters are very much out of my depth.
I'd be very grateful if anyone could offer links or code (in any language) that would help me along in my purpose.
Sounds like an exciting project. I did something similar in the late 90's. Before OpenGL and DirectX became popular, there were a ton of great books on the subject.
Fundamentally you will have to learn how to
Represent 3D geometry
Transform that geometry (translate and rotate)
Project that geometry onto a 2D screen.
Each of those major topics has many sub-topics (for example, complex objects can be constructed from a number of polygons. You may want to limit polygons to being constructed of triangles only, or support other polygons. You may want to load common model formats e.g. .obj files so that you can create models with off the shelf tools).
The topics are way too broad for a detailed answer here. Whole books are written on the subject, including
Black Art of 3D Game Programming (Book, amazingly still available)
For a good introduction to the general topics, have a look at:
http://en.wikipedia.org/wiki/3D_projection
http://en.wikipedia.org/wiki/Orthographic_projection
http://en.wikipedia.org/wiki/Transformation_matrix#Perspective_projection
Doom, which you already looked at, used a special optimization called heightfield rendering and does not allow for rendering of arbitrary 3D shapes (e.g., you will not find a bridge in Doom that you can walk under).
I have the second edition of Computer Graphics: Principles and Practice in C and it uses SRGP (Simple Raster Graphics Programming) and SIGGRAPH which is a wrap-around SRGP, if you look up articles and papers on graphics research you'll see that both these libraries are used a lot, and they are way more direct and low level than the APIs you mentioned. I'm having a hard time locating them, so if you do, please give a link. Note that the third edition is in WPF, so I cannot guarantee much as to it's usefulness, and I don't know if the second edition is still in print, but I have found numerous references to the book, and it's got it's own page in Wikipedia.
Another solution would be the Win32 API which again does not provide much in terms of rendering, but it is trivial to draw dots and lines onto a window. I have written a few tutorials on it, but I didn't cover drawing pixels and lines, so they'll only be useful if you have trouble with the basics of setting up a window. Note that it is not intended for real-time rendering, so it may get slow.
Finally you can look at X11 programming, the foundation of most modern operating systems with a GUI. I haven't found the libraries for Windows, but again I didn't invest too much time on it. I know it is available for CIGWIN and for Linux in general though, and I believe it would be very interesting to look at the core of graphics since you're already looking under the hood of 3D graphics.
So I stumbled upon this "new" graphics engine/technology called Unlimited Detail.
This seems to be pretty interesting granted it's real and not a fake.
They have some videos explaining the technology but they only scratch the surface.
What do you think about it? Is it programmatically possible?
Or is it just a scam for investors?
Update:
Since the only answer was based on voxels I have to copy this from their site:
Unlimited Details method is very different to any 3D method that has been invented so far. The three current systems used in 3D graphics are Ray tracing polygons and point cloud/voxels, they all have strengths and weaknesses. Polygons runs fast but has poor geometry, Ray-trace and voxels have perfect geometry but run very slowly.
Unlimited Detail is a fourth system, which is more like a search algorithm than a 3D engine
The underlying technology is related to something called sparse voxel octrees (see, e.g., this paper), which aren't anything incredibly amazing. What the video doesn't tell you is that these are not at all suited for things that need to be animated, so they're of limited use for anything that uses procedural animation (e.g., all ragdoll physics, etc.). So they're very inflexible. You can get great detail, but you get it in a completely static world.
A rough summary of where things stand with this technology in mainstream games is here. You will also want to check out Samuli Laine's work; he's a Finnish researcher who is focusing a great deal of his attention on this subject and is unlocking some of the secrets to implementing it well.
Update: Yes, the website says it's not "voxel-based". I suspect this is merely an issue of semantics, however, in that what they're using are essentially voxels, but because it's not exactly a voxel they feel safe in being able to claim that it's not voxel-based. In any case, the magic isn't in how similar to a voxel it is -- it's how they select which voxels to actually show. This is the primary determinant of speed.
Right now, there is no incredibly fast way to show voxels (or something approximating a voxel). So either they have developed a completely new, non-peer-reviewed method for filtering voxels (or something like them), or they're lying.
You might find more detail in the following patents:
"A Computer Graphics Method For Rendering Three Dimensional Scenes"
"A Method For Efficent Streaming Of Octree Data For Access"
- Each voxel (they call it a "node") is represented as a single bit, along with information voxels at a finer level of detail.
The full-text can be viewed online here:
https://www.lens.org/lens/search?q=Euclideon+Pty+Ltd&l=en
or
http://worldwide.espacenet.com/searchResults?submitted=true&query=EUCLIDEON
Will you please provide me a reference to help me understand how scanline based rendering engines works?
I want to implement a 2D rendering engine which can support region-based clipping, basic shape drawing and filling with anti aliasing, and basic transformations (Perspective, Rotation, Scaling). I need algorithms which give priority to performance rather than quality because I want to implement it for embedded systems with no fpu.
I'm probably showing my age, but I still love my copy of Foley, Feiner, van Dam, and Hughes (The White Book).
Jim Blinn had a great column that's available as a book called Jim Blinn's Corner: A Trip Down the Graphics Pipeline.
Both of these are quited dated now, and aside from the principles of 3D geometry, they're not very useful for programming today's powerful pixel pushers.
OTOH, they're probably just perfect for an embedded environment with no GPU or FPU!
Here is a good series of articles by Chris Hecker that covers software rasterization:
http://chrishecker.com/Miscellaneous_Technical_Articles
And here is a site that talks about and includes code for a software rasterizer. It was written for a system that does not have an FPU (the GP2X) and includes source for a fixed point math library.
http://www.trenki.net
I'm not sure about the rest, but I can help you with fast scaling and 2D rotation for ARM (written in assembly language). Check out a demo:
http://www.modaco.com/content/smartphone-software-games/291993/bbgfx-2d-graphics-library-beta/
L.B.