KGL Clipping Issue

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
111
DCEmu Junior
DCEmu Junior
Posts: 42
https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
Joined: Thu Jul 07, 2016 7:11 pm
Has thanked: 0
Been thanked: 6 times

KGL Clipping Issue

Post by 111 »

===============================
Not sure if it is an appropriate thread (couldn't find anything like "general KGL thread"), but here goes...

I have some weird (clipping?) issues. Here is a test scene:
Spoiler!
Image

sometimes it looks fine (especially when camera is zoomed out a lot (which means everything is in the viewing frustum I guess)), sometimes it doesn't:
Spoiler!
Image
Calling "glDisable(GL_KOS_NEARZ_CLIPPING)" has no effect, as well as changing z-near value for projection.

Here is a selfbootable cdi of the above demo:
https://www.sendspace.com/file/yj52mk

Controls: DPAD - move player, A\Y - move camera up\down, X\B - zoom in\out, L\R - rotate camera.

I really have no idea what's wrong with this. Any suggestions, please?
Everything renders using immediate mode, it that helps.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: KGL Clipping Issue

Post by BlueCrab »

Split to it's own topic. No need to try too hard to find an appropriate topic when you have a question that doesn't fall neatly into another topic.

I don't really have anything to add here, as PH3NOM is the one to ask about GL stuff. :wink:
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: Need some help with KOS

Post by bogglez »

111, it's ok to open an own thread.
Your camera's near plane is colliding with the geometry. Basically the ground is trying to stick out of the monitor and stab you in the face.
The OpenGL implementation needs to clip the part of the floor that would stick out of the monitor, otherwise you would see graphical artifacts. That's why you can see through the floor.
You should post the projection matrix you're using, or call to gluPerspective/Ortho.
Assuming those matrices are correct, you'll have to do collision detection with the scene to disallow the camera to see through walls/floors.
Wiki & tutorials: http://dcemulation.org/?title=Development
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream
111
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Thu Jul 07, 2016 7:11 pm
Has thanked: 0
Been thanked: 6 times

Re: KGL Clipping Issue

Post by 111 »

BlueCrab wrote:Split to it's own topic. No need to try too hard to find an appropriate topic when you have a question that doesn't fall neatly into another topic.
bogglez wrote:111, it's ok to open an own thread.
ok, got it.
bogglez wrote: Your camera's near plane is colliding with the geometry. Basically the ground is trying to stick out of the monitor and stab you in the face.
The OpenGL implementation needs to clip the part of the floor that would stick out of the monitor, otherwise you would see graphical artifacts. That's why you can see through the floor.
if that is the case, then why changing z_near value does nothing? I even went as far as setting it above 1.0f (up to 10-20) and there was not much difference (if at all).
And it doesn't happen only with floor (I suppose you have not tried the demo yet?)
You should post the projection matrix you're using, or call to gluPerspective/Ortho.

Code: Select all

gluPerspective(45.0f, 640.0f / 480.0f, 0.1f, 1000.0f);
I also use custom matrix to transform camera position and then multiply it with current model view before rendering everything else. Replacing it (partially) with gluLookAt() doesn't change anything, so I think implementation is correct.
Assuming those matrices are correct, you'll have to do collision detection with the scene to disallow the camera to see through walls/floors.
... I don't really get it, sorry. The question is how I am supposed to "disallow see through" in the first place. Otherwise, what's the point of collision checks (aside from frustum culling, which is not there yet)?
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: KGL Clipping Issue

Post by bogglez »

111 wrote:
bogglez wrote: Your camera's near plane is colliding with the geometry. Basically the ground is trying to stick out of the monitor and stab you in the face.
The OpenGL implementation needs to clip the part of the floor that would stick out of the monitor, otherwise you would see graphical artifacts. That's why you can see through the floor.
if that is the case, then why changing z_near value does nothing? I even went as far as setting it above 1.0f (up to 10-20) and there was not much difference (if at all).
And it doesn't happen only with floor (I suppose you have not tried the demo yet?)
I said scene, not just floor.
You should post the projection matrix you're using, or call to gluPerspective/Ortho.

Code: Select all

gluPerspective(45.0f, 640.0f / 480.0f, 0.1f, 1000.0f);
I also use custom matrix to transform camera position and then multiply it with current model view before rendering everything else. Replacing it (partially) with gluLookAt() doesn't change anything, so I think implementation is correct.
Setting z to a higher value will cut off even more geometry, since the clipping plane will be further forward.
0.1f in your gluPerspective call looks good though. Since you don't post any math or source code I can only guess (and that's not fun tbh).
I'd try reducing 1000.f to a smaller value. The interval of 0.1f to 1000.f can cause some precision issues (maybe try 1.f and 100.f).
Also check whether the scene geometry is incredibly huge or tiny (again float precision problems).
Your matrices might also cause this to happen so replace them with an identity matrix where you can for debugging.
Assuming those matrices are correct, you'll have to do collision detection with the scene to disallow the camera to see through walls/floors.
... I don't really get it, sorry. The question is how I am supposed to "disallow see through" in the first place. Otherwise, what's the point of collision checks (aside from frustum culling, which is not there yet)?
Seeing through walls will always be possible because polygons are not solid and your meshes don't actually have anything inside of them. To keep the illusion alive you can not allow the near plane of the camera to intersect with geometry.
Wiki & tutorials: http://dcemulation.org/?title=Development
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: KGL Clipping Issue

Post by bogglez »

(double post)
Wiki & tutorials: http://dcemulation.org/?title=Development
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream
111
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Thu Jul 07, 2016 7:11 pm
Has thanked: 0
Been thanked: 6 times

Re: KGL Clipping Issue

Post by 111 »

bogglez wrote: Setting z to a higher value will cut off even more geometry, since the clipping plane will be further forward.
yes, that's exactly what I expected to see. But as I said, almost nothing changed.
I'd try reducing 1000.f to a smaller value. The interval of 0.1f to 1000.f can cause some precision issues (maybe try 1.f and 100.f).
it was 100.f originally. Again, no difference with changing that.
Also check whether the scene geometry is incredibly huge or tiny (again float precision problems).
well it is indeed kinda huge, but scaling it down didn't solve the issue.
Your matrices might also cause this to happen so replace them with an identity matrix where you can for debugging.
guess I'll try to just translate everything without "camera". Will post the results later (upd: checked. Same result)
Seeing through walls will always be possible because polygons are not solid and your meshes don't actually have anything inside of them. To keep the illusion alive you can not allow the near plane of the camera to intersect with geometry.
camera is not supposed to move through walls, there is just no collision code for it right now.
Even if it's all about the near plane, why does it clip the entire triangle? It should not work that way. I don't know how to explain, so here is a picture of correct behavior:

Image

should be self-explanatory I guess.
Last edited by 111 on Mon Jul 11, 2016 11:19 pm, edited 1 time in total.
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: KGL Clipping Issue

Post by PH3NOM »

Calling "glDisable(GL_KOS_NEARZ_CLIPPING)" has no effect
You need to enable NearZ Clipping:

Code: Select all

glEnable(GL_KOS_NEARZ_CLIPPING);
And this needs to be called before glBegin() if you are using immediate mode...

Your posts did not mention that you have tried that...
111
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Thu Jul 07, 2016 7:11 pm
Has thanked: 0
Been thanked: 6 times

Re: KGL Clipping Issue

Post by 111 »

PH3NOM wrote: You need to enable NearZ Clipping:

Code: Select all

glEnable(GL_KOS_NEARZ_CLIPPING);
just tried that. Still no luck :(

Code: Select all

	glEnable(GL_KOS_NEARZ_CLIPPING);
	glBegin(GL_TRIANGLES);
		msh_render_IM(&msh_player); /* there is no glBegin() in that routine, only IM calls*/
	glEnd();
/*	glDisable(GL_KOS_NEARZ_CLIPPING);   <----   uncommenting this also has no effect*/
111
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Thu Jul 07, 2016 7:11 pm
Has thanked: 0
Been thanked: 6 times

Re: KGL Clipping Issue

Post by 111 »

So I've read this:
http://gamedev.stackexchange.com/questi ... -disappear

and this:
http://stackoverflow.com/questions/7378 ... e-calculus


From one of the answers, I guess current KGL implementation is done this way:
if any point in the polygon falls behind the near plane, then don't draw the entire polygon. This is simple but usually unacceptable. Compare each point against the near plane (if polygon.points.z < near.z). But this will make polygons disappear and reappear seemingly randomly at the edges of the screen.


unfortunately, I don't think I can fix this myself :\
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: KGL Clipping Issue

Post by PH3NOM »

111 wrote:So I've read this:
http://gamedev.stackexchange.com/questi ... -disappear

and this:
http://stackoverflow.com/questions/7378 ... e-calculus


From one of the answers, I guess current KGL implementation is done this way:
if any point in the polygon falls behind the near plane, then don't draw the entire polygon. This is simple but usually unacceptable. Compare each point against the near plane (if polygon.points.z < near.z). But this will make polygons disappear and reappear seemingly randomly at the edges of the screen.


unfortunately, I don't think I can fix this myself :\


What you are referring to, I call culling.
And no, that is not how the clipping works in KGL :lol:

I perform slicing on the triangles to tessellate new triangles that do not intersect the NearZ plane.
In fact, I have personally written the algorithm from scratch.
If you are curious, look at gl-clip.c and gl-clip-arrays.c for my implementation :lol:

And its usage has been demonstrated in some of the KGL examples.
A good example is on kos\examples\dreamcast\kgl\demos\specular

Can you optimize your code to use arrays instead of immediate mode?
I am curious if that changes anything, as you can see I have written 2 source files to handle each case uniquely.

That said, there is one value you can change in KGL to change the clipping distance.
on gl-clip.h you see this
#define CLIP_NEARZ -1.0f /* Clip Threshold */

You can change that value and do a clean re-build of the lib to change the NearZ Clipping Plane value, but likely the problem is elsewhere.

Can you post your matrix code?
At one point you say this:
I also use custom matrix to transform camera position and then multiply it with current model view before rendering everything else. Replacing it (partially) with gluLookAt() doesn't change anything, so I think implementation is correct.


Can you avoid using custom matrices for a test? I would have to look closer at your matrix code to see if you are doing something my API is not expecting...
111
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Thu Jul 07, 2016 7:11 pm
Has thanked: 0
Been thanked: 6 times

Re: KGL Clipping Issue

Post by 111 »

PH3NOM wrote: Can you optimize your code to use arrays instead of immediate mode?
I am curious if that changes anything, as you can see I have written 2 source files to handle each case uniquely.
tried that. Same result.
You can change that value and do a clean re-build of the lib to change the NearZ Clipping Plane value, but likely the problem is elsewhere.
... and how exactly should I do this? Making a clean re-build wipes all the source files it seems (after downloading and compiling them first).
Sorry, I know almost nothing about makefiles and all of that gcc/linux stuff.

Can you avoid using custom matrices for a test?
already tried that as well,
guess I'll try to just translate everything without "camera". Will post the results later (upd: checked. Same result)
to be specific, I replaced everything with a single glTranslatef()

actually, I even tried all of the above with older version of kos\kgl (the one that is bundled with DCDev iso R4). Guess what I got?
My last assumption is that MAYBE there is something wrong with my custom file formats. But that is unlikely the case because:
- it is as minimalistic as possible
- rendering would be screwed up from any distance, not only when "camera" is close.

Seriously, I am really close to just give up now
[s]and switch to official SDKs (and yes, I'm aware that it is not allowed to discuss here).[/s]

-----
But thank you for taking the time to respond to me.
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: KGL Clipping Issue

Post by bogglez »

I have never had those issues, so something's definitely weird. Especially because I think that the r4 doesn't even perform clipping. (?)
Have you considered creating a Windows/Linux executable and comparing that to the Dreamcast executable? That would make sure the opengl implementation is correct.
Wiki & tutorials: http://dcemulation.org/?title=Development
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream
111
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Thu Jul 07, 2016 7:11 pm
Has thanked: 0
Been thanked: 6 times

Re: KGL Clipping Issue

Post by 111 »

bogglez wrote: Have you considered creating a Windows/Linux executable and comparing that to the Dreamcast executable? That would make sure the opengl implementation is correct.
... but isn't KGL is a wrapper for pvr api? How is it possible to build windows executable with it?

And if it was not clear, I do develop on Windows with GL first, then I mostly copy-paste everything to my KGL template (which is based on the included examples).
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: KGL Clipping Issue

Post by bogglez »

111 wrote:
bogglez wrote: Have you considered creating a Windows/Linux executable and comparing that to the Dreamcast executable? That would make sure the opengl implementation is correct.
... but isn't KGL is a wrapper for pvr api? How is it possible to build windows executable with it?

And if it was not clear, I do develop on Windows with GL first, then I mostly copy-paste everything to my KGL template (which is based on the included examples).
Of course i didn't mean that you should use the Dreamcast opengl implementation on PC.
Make a Windows executable that links to nvidia/ATI drivers. If the windows executable also looks bad then your program is definitely at fault.
If it looks correct, then the problem is Dreamcast hardware or kgl specific.
Wiki & tutorials: http://dcemulation.org/?title=Development
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream
111
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Thu Jul 07, 2016 7:11 pm
Has thanked: 0
Been thanked: 6 times

Re: KGL Clipping Issue

Post by 111 »

bogglez wrote: Make a Windows executable that links to nvidia/ATI drivers. If the windows executable also looks bad then your program is definitely at fault.
I use visual c++ and link with opengl32.lib and glu32.lib. What do you mean by "link to nvidia/ATI drivers"? I have an AMD GPU, if that matters.

I have a better idea. Here is an example project:
https://www.sendspace.com/file/g0heel
everything works fine on Windows, but not with KGL.

Because seriously, I understand that nobody owe anything to anyone, but I'm getting tired of "you're stupid\doing it wrong" attitude.
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: KGL Clipping Issue

Post by bogglez »

Opengl32.lib is your AMD driver, so you're already doing that (as you said in your previous post). Does the result look correct on Windows?

Nobody here said you're stupid or doing it wrong. I suggested the comparison with Windows to find out where the problem is. We've never seen this problem in other opengl programs so we're trying to find out whether that's really it.
Wiki & tutorials: http://dcemulation.org/?title=Development
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream
111
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Thu Jul 07, 2016 7:11 pm
Has thanked: 0
Been thanked: 6 times

Re: KGL Clipping Issue

Post by 111 »

bogglez wrote:Opengl32.lib is your AMD driver, so you're already doing that (as you said in your previous post). Does the result look correct on Windows?

Nobody here said you're stupid or doing it wrong. I suggested the comparison with Windows to find out where the problem is. We've never seen this problem in other opengl programs so we're trying to find out whether that's really it.
And if it was not clear, I do develop on Windows with GL first, then I mostly copy-paste everything to my KGL template (which is based on the included examples).
why would I want to port a broken program in the first place?
also this:
111 wrote: here is a picture of correct behavior:
Image
should be self-explanatory I guess.
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: KGL Clipping Issue

Post by bogglez »

Is this more like what you expected?

(And seriously please stop being so toxic. I'm about to leave this thread. This is not how you ask for help.)
Attachments
objloader_fix_bogglez.7z
(688.26 KiB) Downloaded 86 times
Wiki & tutorials: http://dcemulation.org/?title=Development
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream
111
DCEmu Junior
DCEmu Junior
Posts: 42
Joined: Thu Jul 07, 2016 7:11 pm
Has thanked: 0
Been thanked: 6 times

Re: KGL Clipping Issue

Post by 111 »

bogglez wrote:Is this more like what you expected?
aside from missing texture filtering - yes.

("lvl.obj" is still rendered incorrectly though, no clipping issues, it is just does not look the way it should)
Post Reply