Hi guys,

my question might sound stupid and maybe there's no clear answer for it but I'd really like your opinion about it... ^_^

I'm doing some research about rendering currently and I stumbled about the terms "2D rendering (engines)" and "2D sprite rendering" quite a few times. My understanding was that "rendering" was the process of creating a 2D-image from the current state of a 3D-model (or various 3D-models making up a 3D-scene) in consideration of a viewpoint, lighting, texture, etc. and if the process is meant to happen in real-time, this image is directly drawn to the screen. Now, if I have 2D-data (sprites, bitmaps or however you want to call it...) that makes up a 2D-scene or a GUI-system there's no need for "rendering" in my opinion. All that needs to be done with this data is to draw it on the screen. Is it common to use "rendering" interchangeably to "drawing" in 2D-context or what does it mean in this context?

BR

koS.

Now, if I have 2D-data (sprites, bitmaps or however you want to call it...) that makes up a 2D-scene or a GUI-system there's no need for "rendering" in my opinion. All that needs to be done with this data is to draw it on the screen.

It's not that simple. Almost every game has some form of depth, varying from static "background" images, to multiple levels of layers where the player can move before/behind, to isometric game worlds, where the entire world is rotated 45 degrees.

With a GPU, you can just sort pixels on depth. Without GPU (or without depth sorting of pixels), you have to draw sprites in the correct order, otherwise the depth illusion breaks. For games like Rollercoaster Tycoon, this is not quite trivial.

As a result, drawing 2D sprites is more than just bltting.

Thanks for your input, HappyCoder and Alberth.

So, what I understand is, that "rendering" and "drawing" are used interchangeably, both in 2D- and 3D-context. Right?

I'm actually looking for a "high-level" definition for real-time 2D-rendering and 3D-rendering. What do you think about the following definitions?

real-time 3D-rendering: process of generating a 2D-image from a 3D-model (or various 3D-models making up a 3D-scene) in consideration of viewpoint, lighting, texture, etc. and drawing it directly to the screen.

real-time 2D-rendering: process of drawing a 2D-image directly to screen (blitting) or generating a 2D-image from various 2D-images in consideration of the layers that make up a 2D-scene (ie. background, center, foreground) and drawing it directly to the screen.

I'm looking forward to your feedback.

BR

koS.

and drawing it directly to the screen.

Doesn't necessarily apply to eigther 3D or 2D. All forms of rendering might very vell draw the scene to some sort of intermedia-offscreen buffer(s), for later use in postprocessing.

process of generating a 2D-image from a 3D-model (or various 3D-models making up a 3D-scene) in consideration of viewpoint, lighting, texture,

Lighting can also be part of a 2d-pipeline, see games like "Enter the gungeon".

Viewports can also be part of a 2D-game (ie. minimap in a 2D RTS). Some 2d-renderers even use a regular camera/matrix akin to a 3d renderer with a orthographic projection (ie. Unity)

Texture and images are exactly the same in the context of rendering. One could argue that 2d and 3d have vastly different applications for textures, but thats mostly up to the specific use case (ie. a 2d game with dynamic lighting might as well some sort of bump-map for the 2D-tiles).

Perhaps 3D just adds a new initial stage. It runs a bunch of vector computations to arrive at (coordinates of) areas where a texture should be blitted. Mostly, from there, 2D and 3D are the same, it's just collections of pixels (from textures or sprites) getting blitted to the destination (video or memory) area, in layers.

The main difference is perhaps that the areas with 3D origin can easily have varying depth within an area, something that wasn't done in 2D due to computation complexity. (At least, in theory you'd just need some form of a depth function associated with the sprite coordinates, which seems very possible if you really wanted.)

Being perfectly honest programming isn't being a doctor, we don't pick labels for names and write them in medical books and teach them for a century. Rendering and drawing are often used interchangeably because they end up meaning the same thing, the process to display something to the screen. Rendering has more of a specific definition in certain aspects, i.e. if you worked at a movie studio they'd probably be more picky about the word "rendering" but they also leave games out of the definition process of things like that because it's such an informal industry.

My question is why do you need a definition? These days 2d rendering is all done with the 3d graphics pipeline, just a bunch of quads with textures stuck to them. Blitting sounds like it would be faster in theory but like most things the GPU is faster because it works in parallel and also takes up time that the cpu doesn't have to spend doing things.

Personally I use both words without really ever thinking about it.

My question is why do you need a definition? These days 2d rendering is all done with the 3d graphics pipeline, just a bunch of quads with textures stuck to them. Blitting sounds like it would be faster in theory but like most things the GPU is faster because it works in parallel and also takes up time that the cpu doesn't have to spend doing things. Personally I use both words without really ever thinking about it.

To answer your question: I'm currently working on a project with a mechanical engineering background. Its goal is to develop an offline-programming environment for an industrial robot with a game engine. I'm searching for definitions as I need to cover some theory in the project report as I can not assume that every reader (mechanical engineer) is familiar with what a game engine is or what a rendering engine does. I - myself - like it when there's a high-level definition of terms I'm not familiar with instead of being confronted with them in a report without any explanation. I hope this clears things up and doesn't let me sound like a total nitpicker... ^_^

@Juliean & Alberth: THX!

BR

koS.

My question is why do you need a definition? These days 2d rendering is all done with the 3d graphics pipeline, just a bunch of quads with textures stuck to them. Blitting sounds like it would be faster in theory but like most things the GPU is faster because it works in parallel and also takes up time that the cpu doesn't have to spend doing things. Personally I use both words without really ever thinking about it.

To answer your question: I'm currently working on a project with a mechanical engineering background. Its goal is to develop an offline-programming environment for an industrial robot with a game engine. I'm searching for definitions as I need to cover some theory in the project report as I can not assume that every reader (mechanical engineer) is familiar with what a game engine is or what a rendering engine does. I - myself - like it when there's a high-level definition of terms I'm not familiar with instead of being confronted with them in a report without any explanation. I hope this clears things up and doesn't let me sound like a total nitpicker... ^_^

@Juliean & Alberth: THX!

BR

koS.

I'm not sure what the specific definition of rendering is in this case, if you look online or in books you get rather obtuse definitions. You would probably think of rendering and immediately think "taking some data and converting it to display color information to a screen."

Problem is rendering isn't just used for that. That definition falls apart a bit when we talk about things like rendering to textures, which is used a lot to composite final screen image data but people go and use it for things that never get shown on the screen as well. You might just want to pick a textbook or something and go off their definition of it because I don't think there's a great consensus on what the word means in practice vs academia.