[2.7.1] Bug with voxelmodels mapping

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Post Reply
Uberkreatur
Posts: 27
Joined: Fri Dec 26, 2014 10:54 am
Location: Russia

[2.7.1] Bug with voxelmodels mapping

Post by Uberkreatur »

(Oh, sorry for my bad english.)

I experimented with voxelmodels and found, that upper model is always visible on top of the lower irrespective of the camera position. Sometimes it has bad result.
This depends on the relative position of center of the decorate actors on Z-coordinate.
ImageImage
ImageImage

Maybe, render mechanism needs some improvement, that will follow z-position of player camera to make mapping priority like on x and y-coordinates.
Attachments
bug_voxel_models.pk3
Demonstration of the voxel bugs
(215.01 KiB) Downloaded 57 times
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49223
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: [2.7.1] Bug with voxelmodels mapping

Post by Graf Zahl »

Don't expect this to be fixed. The limitations of the software renderer mean that proper 3D positioning of overlapping models is impossible.
Gez
 
 
Posts: 17938
Joined: Fri Jul 06, 2007 3:22 pm

Re: [2.7.1] Bug with voxelmodels mapping

Post by Gez »

User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49223
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: [2.7.1] Bug with voxelmodels mapping

Post by Graf Zahl »

Yup, same problem. Not fixable.
Uberkreatur
Posts: 27
Joined: Fri Dec 26, 2014 10:54 am
Location: Russia

Re: [2.7.1] Bug with voxelmodels mapping

Post by Uberkreatur »

Graf Zahl wrote:Don't expect this to be fixed. The limitations of the software renderer mean that proper 3D positioning of overlapping models is impossible.
But I have already done that! :mrgreen:
ImageImage
ImageImage

Here is simple hack, which selects a mapping order depending on player Z-position.

Code: Select all

script 956 (void) 
{
SetActorAngle (3000, GetActorAngle(3000)+40);
  if (GetActorZ(2000)>(GetActorZ(0)+589824))
		 {
         SetActorPosition(3000,GetActorX(3000),GetActorY(3000),GetActorZ(3000), 0);
		 }
  else
		 {
         SetActorPosition(0,GetActorX(0),GetActorY(0),GetActorZ(0), 0);
		 }
}
When two models have the same XY-coordinates, render puts on the top that one, which was affected with last "SetActorPosition" operation.
Maybe it is possible to make some "visibility flags" to simplify and adapt this trick to the multiplayer mode?
Attachments
hack_voxel_models.pk3
voxel positioning hack
(185.52 KiB) Downloaded 55 times
User avatar
edward850
Posts: 5886
Joined: Tue Jul 19, 2005 9:06 pm
Location: New Zealand
Contact:

Re: [2.7.1] Bug with voxelmodels mapping

Post by edward850 »

Maximum kludge != fixing anything.
User avatar
Xaser
 
 
Posts: 10774
Joined: Sun Jul 20, 2003 12:15 pm
Contact:

Re: [2.7.1] Bug with voxelmodels mapping

Post by Xaser »

What'd be the correct alternative you'd suggest?
User avatar
edward850
Posts: 5886
Joined: Tue Jul 19, 2005 9:06 pm
Location: New Zealand
Contact:

Re: [2.7.1] Bug with voxelmodels mapping

Post by edward850 »

Assuming we're still talking about an actual engine fix, something that doesn't absurdly change actor Z heights. :P
Uberkreatur
Posts: 27
Joined: Fri Dec 26, 2014 10:54 am
Location: Russia

Re: [2.7.1] Bug with voxelmodels mapping

Post by Uberkreatur »

edward850 wrote:Maximum kludge != fixing anything.
This kludge demonstrates specifics of sowtware work. I found, that:
1. To the render it does not matter, which model have most Z-coordinate.
2. Render puts on the top that one, which was affected with last moving operation. Even if model was moved to the same place.

My hack does not change Z-coordinates. It makes formal moving operation to the same coordinate, like walking in place.
I imagine algorithm of bugfix like that:
Image
1. Two models have same XY-coordinates and +checkZpos flag.
2. Player cameras check deflection of visual beam from the normal.
3.1. If α and β angles have both negative values, then model 2 considering above model 1 for the render.
3.2. If α and β angles have both positive values, then model 2 considering below model 1 for the render.
3.3. If α angle has positive value, and β angle has negative value, then:
3.3.1. If radius 1 is more than radius 2, then model 2 considering below model 1 for the render.
3.3.2. If radius 2 is more than radius 1, then model 2 considering above model 1 for the render.
4. Now render system knows, which model needs to be visually moved on the top.
(4.1. One of the way to do that is formal moving operation, which would not synchronise between players.)
5. ???
6. Profit.
Post Reply

Return to “Closed Bugs [GZDoom]”