[A5] Allegro display depth buffer?

BitCruncher

This is a noob question, but as of 5.2.4, why are there display options referring to depth buffers if the software rasterizer can't render 3D primitives?

Is there 3D rendering support as of today?

Edgar Reynaldo

There has been hardware accelerated 3D drawing support for quite some time. Whether there's a software rasterizer I don't know.

Elias

The software rasterizer does not support depth buffers (or any other buffers besides the basic RGB).

As for the hardware renderer, Allegro has quite a few primitives which supports 3D, like al_draw_vertex_buffer and of course full support for shaders (al_user_shader)!

BitCruncher

Hmm. I see. Can the hardware renderer do z-buffering? For example, is there a function that draws polygons while performing pixel depth-based occlusion?

Edgar Reynaldo

yes, enable the depth buffer when creating the display, and then turn on depth occlusion

Chris Katko

https://www.allegro.cc/manual/5/al_set_new_display_option

ALLEGRO_DEPTH_SIZE

Edgar Reynaldo

Ghack! Katko! Link to liballeg...

al_set_new_display_option

Chris Katko

I just google the name. I don't know why the old docs are still at the top of google.

Edgar Reynaldo

Because allegro.cc is more popular than liballeg.org . :/

BitCruncher

Having some issues now with z-buffer artifacts...

Attached a picture of what's supposed to be a cube, but the faces are getting drawn weird.

Here's a snippet of my display creation + options:

#SelectExpand
  1// ****************************************************
  2// set up display
  3// ****************************************************
  4// this option is set in order to enforce only one page buffer
  5al_set_new_display_option(ALLEGRO_SINGLE_BUFFER, 1, ALLEGRO_REQUIRE);
  6al_set_new_display_option(ALLEGRO_FLOAT_DEPTH, 1, ALLEGRO_REQUIRE);
  7al_set_new_display_option(ALLEGRO_DEPTH_SIZE, 32, ALLEGRO_REQUIRE);
  8al_set_new_display_option(ALLEGRO_STENCIL_SIZE, 8, ALLEGRO_REQUIRE);
  9// al_set_new_display_option(ALLEGRO_RENDER_METHOD, 1, ALLEGRO_REQUIRE);
 10// al_set_new_display_option(ALLEGRO_SAMPLE_BUFFERS, 1, ALLEGRO_REQUIRE);
 11// al_set_new_display_option(ALLEGRO_SAMPLES, 8, ALLEGRO_REQUIRE);
 12mainDisplay = al_create_display(displayWidth, displayHeight);
 13mainDisplayEventSource = al_get_display_event_source(mainDisplay);
 14al_set_target_backbuffer(mainDisplay);

Also the transforms:

#SelectExpand
 1const int DEPTH = 1000000;
 2
 3// left = 0, top = 0, near = -1000, right = displayWidth, bottom = displayHeight, far = +1000
 4al_identity_transform(&transform);
 5al_orthographic_transform(&transform, 0, 0, -DEPTH, displayWidth, displayHeight, +DEPTH);
 6al_use_projection_transform(&transform);

And the actual drawing:

#SelectExpand
 1al_set_render_state(ALLEGRO_DEPTH_TEST, 1);
 2al_clear_depth_buffer(10000);
 3al_draw_prim(vertList, nullptr, nullptr, 0, 240, ALLEGRO_PRIM_TRIANGLE_LIST);

No, there isn't 240 actual vertices in buffer, but I get the same results even if the drawing was confined to the cube itself.

I made sure the cubes depth is within the clipping rectangle so no problems there. Is there anything specific that can cause this?

Edgar Reynaldo

I'm not sure what the problem is, but it might be that the depth buffer is not enabled by default. This would fix that :

al_set_render_state(ALLEGRO_DEPTH_TEST , 1);

Something else to make sure of is to wind your triangle vertices all counter clockwise. Google if you don't know what that means.

BitCruncher

Yes, I think the triangle winding might be off because I notice that on more complex geometries, some of the faces get colored correctly on the outside surface of the volume, but then some faces get colored on the side facing into the volume. May be related, but idk. Checking on this now...

Update #1:
Here is more context and clues. Firstly fyi, the cube I'm trying to draw is triangulated and the red lines in the pictures just show the wireframe. Secondly, I have a simple light source coming in from the right. Now, If I draw each face just using al_draw_filled_polygon() (and NOT al_draw_prim()), the cube is drawn correctly as in image #1. If I switch drawing methods to al_draw_prim() (and NOT al_draw_filled_polygon()), the cube is drawn as shown in image #2 (#3 is just #2 without the wireframe). You can see that somehow, al_draw_prim() is connecting verts that do not form faces...

Edgar Reynaldo

Can you just post a zip of your code for me to play with? It's useful seeing everything all at once.

BitCruncher

Sorry for the delay. I played around with it for just a bit more out of desperation, and found that using a floating point depth buffer was causing issues. Depth occlusion works just fine now, but I'm not sure why...

I'll still post the code anyway when I get back to my PC.

Edgar Reynaldo

Bump for reply.

BitCruncher

Code is up; I had to use Dropbox cause the zip was too big to be attached.

https://www.dropbox.com/s/xsl5wnwrwszfijq/Cube3D.zip?dl=0

Edgar Reynaldo

Hey, that's a cool effect. haha

I'm looking at your code now, just got it running.

BitCruncher

Haha . It's not a bug but a feature, right?

Yeah so if you comment out setting up the floating point depth buffer, then the cube gets drawn normally.

Edgar Reynaldo

Wow, you're totally right.

I redid the poly set for the faces and it was the same, so I removed the floating point buffer requirement, and it was drawn correctly!!! This seems like a bug, as they are being drawn translucently when the depth buffer is floating point.

Thread #617906. Printed from Allegro.cc