Quake 3 lightmaps - PVR Multi-Texture

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.
User avatar
Neoblast
DC Developer
DC Developer
Posts: 314
https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
Joined: Sat Dec 01, 2007 8:51 am
Has thanked: 3 times
Been thanked: 1 time

Re: Quake 3 lightmaps - PVR Multi-Texture

Post by Neoblast »

Your API is awesome, that seriously looks much better than most commercial game graphics from back then.

Are those q3 format maps?
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: Quake 3 lightmaps - PVR Multi-Texture

Post by PH3NOM »

Thanks man yeah these maps are all Quake 3.

The light maps also act as shadow maps, as demonstrated by this large map (10mb bsp) on DC using multi-texture with the latest KGL commit

Image

Image

Image
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: Quake 3 lightmaps - PVR Multi-Texture

Post by bogglez »

PH3NOM wrote:I have actually finished my 2nd pass at the Multi-Texture system, improving performance even further.
My first approach was the obvious one; for every vertex submitted, after all processing is done(lighting, transforming, clipping, etc.), copy the resulting vertex into the TR vertex buffer with the 2nd u/v set.

This requires storing each vertex twice in the vertex buffer, as well as memory time for copying each vertex.

My new approach does not consume any extra space in the vertex buffer, as it actually modifies the existing vertices in the vertex buffer as a post-process after the original vertices have already been submitted to the pvr. This approach only requires the memory time of copying each u/v set, rather than the entire vertex.
I didn't quite understand that description, I'll check out the code later :P
PH3NOM wrote: This map saves ~3msec/frame, and now sails at 60fps with ZClipping and Multi-Texturing every vertex submitted, running just over 2mil verts/sec
This bigger map saves ~5msec/frame, again with ZClipping and Multi-Texturing every vertex submitted, running just over 2.5mil verts/sec
Wasn't Sonic Adventure 2 at 2.5mil verts/sec as well, without multitexturing and without clipping everything?
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
bbmario
DCEmu Freak
DCEmu Freak
Posts: 88
Joined: Wed Feb 05, 2014 5:58 am
Has thanked: 9 times
Been thanked: 3 times

Re: Quake 3 lightmaps - PVR Multi-Texture

Post by bbmario »

PH3NOM, what's the resolution of the textures and the lightmaps? The lightmaps seem very detailed but the textures appear washed out.
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: Quake 3 lightmaps - PVR Multi-Texture

Post by PH3NOM »

bbmario wrote:PH3NOM, what's the resolution of the textures and the lightmaps? The lightmaps seem very detailed but the textures appear washed out.
Good observation.
The Light Maps there are full resolution as stored in the BSP.
The textures were jpg reduced to 1/4 original size.

However, I am realizing the light maps will need to be compressed to get better texture quality, as this map uses 2mb of VRAM just for light maps.
Right now I made a test reducing lm resolution to 1/2 size by generating mip-map levels with gl, and then uploading the 1st mip-map level as the base texture, this saves ~1.5mb VRAM on this map.
My end game would be to apply vq compression during run-time on the light-maps to get the same memory saving without reducing resolution.

So on this test, light maps are 1/2 res and textures are full res with vq compression on the square textures, 1/2 res for rectangle jpg's

Do you think this is any better?

Image

Image
User avatar
bbmario
DCEmu Freak
DCEmu Freak
Posts: 88
Joined: Wed Feb 05, 2014 5:58 am
Has thanked: 9 times
Been thanked: 3 times

Re: Quake 3 lightmaps - PVR Multi-Texture

Post by bbmario »

It looks MUCH better now. Amazing! I'm eager to start working on your BSP rendering code and my Bullet physics port. :grin:
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: Quake 3 lightmaps - PVR Multi-Texture

Post by bogglez »

1. Why not VQ compress during build time? Are the textures inside of the map?
2. Is texture filtering off? If you twiddle the textures (e.g. during glTexImage2D or manually before calling it), bilinear filtering becomes free on the PVR.
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
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: Quake 3 lightmaps - PVR Multi-Texture

Post by PH3NOM »

The Light Maps are encoded into the BSP file itself, so there is no way to compress the Light Maps during build time.
However, my test reveals that VQ compression on the SH4 is VERY slow :(
Something like ~1minute for a single 256x256 pixel texture using the high-quality encoding method, so it is not realistic to compress ~64 textures on loading of a BSP unless you expect the player to wait for an hour for the map to load :lol:

And yeah twiddled textures filter faster on the PVR, but twiddling an un-twiddled texture ( for example, loading a texture using pvr_txr_load_ex ) slows things down, so streaming textures while twiddling is probably out of the window
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: Quake 3 lightmaps - PVR Multi-Texture

Post by PH3NOM »

Yayo. Just a Bump.

Added Collision Detection, and a Sky Box.

Still using multi-texture.

Image

UTubeVideo showing some code and a run of the code in DeMUL:

https://www.youtube.com/watch?v=_d1vvYn1RvY
User avatar
hilltopper06
DCEmu Crazy Poster
DCEmu Crazy Poster
Posts: 26
Joined: Mon Sep 21, 2009 10:39 pm
Has thanked: 0
Been thanked: 0

Re: Quake 3 lightmaps - PVR Multi-Texture

Post by hilltopper06 »

Very impressive. It looks like the textures are a bit blurry (similar to your earlier example that you then improved by 1/2 lightmap resolution). Amazing work though!
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: Quake 3 lightmaps - PVR Multi-Texture

Post by PH3NOM »

Playing around with Collision Detection.

Here I am experimenting with a Flash Light effect achieved through use of the Collision System.
The Flash Light is a Ray that I trace in the direction of the Camera, until it hits a surface.
This Ray trace could also be used for tracing projectiles; i.e. find the position a bullet hits a wall.

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: Quake 3 lightmaps - PVR Multi-Texture

Post by PH3NOM »

Teleports have been added. I have always wanted to see a Portal style game on DC :-)

User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: Quake 3 lightmaps - PVR Multi-Texture

Post by bogglez »

PH3NOM wrote:Playing around with Collision Detection.

Here I am experimenting with a Flash Light effect achieved through use of the Collision System.
The Flash Light is a Ray that I trace in the direction of the Camera, until it hits a surface.
This Ray trace could also be used for tracing projectiles; i.e. find the position a bullet hits a wall.

Shouldn't the flashlight quad become bigger and more transparent proportional to the distance?
Eagerly following your work :)
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
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: Quake 3 lightmaps - PVR Multi-Texture

Post by PH3NOM »

About the light, you are right, I had the distance equation inverted in that test :oops:

This test from today demonstrates using a Render-To-Texture effect to help achieve a better looking Portal:
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: Quake 3 lightmaps - PVR Multi-Texture

Post by bogglez »

Hehehe, what happens when you point a flashlight at a portal? :P

Fun aside, I assume this is using the FBO GL extension?

Later in the video when you move the portal the portal's content seems to update only every other frame. Did you do this for performance reasons? What's the resolution of the texture?

BTW I didn't check your vertex transformation assembly code in detail, but I think you didn't implement texture matrices. Maybe they would allow you to apply a cool effect.

And how did you create the portal border? Looks really cool. Maybe a bit too wide though.
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
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: Quake 3 lightmaps - PVR Multi-Texture

Post by PH3NOM »

bogglez wrote:Hehehe, what happens when you point a flashlight at a portal? :P

Fun aside, I assume this is using the FBO GL extension?

Later in the video when you move the portal the portal's content seems to update only every other frame. Did you do this for performance reasons? What's the resolution of the texture?

BTW I didn't check your vertex transformation assembly code in detail, but I think you didn't implement texture matrices. Maybe they would allow you to apply a cool effect.

And how did you create the portal border? Looks really cool. Maybe a bit too wide though.
Well, truth be told, I am no longer using OpenGL with this code :o
I have developed an even lower-level interface to access the DC's hardware.
The main reason was due to memory loading large BSP's, and speed as a bi-product.
OpenGL must buffer vertices to support the PVR's inability to switch between blended and opaque polys at any time.
As such, OpenGL uses over 4mb of RAM in its current form.

Speed wise, using OpenGL, drawing arrays looks like this:
client data -> opengl -> sh4 buffer -> pvr

In my current DCE API, drawing arrays looks like this:
client data -> sh4 assembly -> pvr

Its closer to the metal, as they say, so all drawing routines must be organized by opaque / translucent, and must be submitted as such.

The Portal is rendered to texture every frame, I guess you are looking at the Source (Blue) Portal in the video.
The Source Portal renders the Destination Portal Perspective, so moving the Source Portal does not change its texture.
Moving the Dest Portal changes the Source texture, so watch when the Red Portal moves. It updates every frame.

My first idea was to render a blended poly ( quad sprite ) on top of the portals render-to-texture, to create the border.
But that seemed too boring, so I created that effect by overlaying multiple rotating sprites in different directions, with different speed and depth to create a volumetric 3D effect.

The latest build renders now renders everything in the scene from the Dest Portals perspective ( this includes the Source Portal, creating an infinite reflection, as well as the Player model )

Image
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: Quake 3 lightmaps - PVR Multi-Texture

Post by bogglez »

PH3NOM wrote: Well, truth be told, I am no longer using OpenGL with this code :o
I have developed an even lower-level interface to access the DC's hardware.
The main reason was due to memory loading large BSP's, and speed as a bi-product.
OpenGL must buffer vertices to support the PVR's inability to switch between blended and opaque polys at any time.
As such, OpenGL uses over 4mb of RAM in its current form.

Speed wise, using OpenGL, drawing arrays looks like this:
client data -> opengl -> sh4 buffer -> pvr

In my current DCE API, drawing arrays looks like this:
client data -> sh4 assembly -> pvr

Its closer to the metal, as they say, so all drawing routines must be organized by opaque / translucent, and must be submitted as such.
Hm, not sure whether it's worth abandoning GL for that. Wouldn't it be easier to add a define that controls whether the passes may be mixed or need to occur in the PVR's native order? So once blending has been activated it's not possible to submit opaque polygons anymore (or they'll get rendered with blending on but set to opaque). That would also remove the vertex buckets for the different modes, but still allow using GL instead of a new API.
The Portal is rendered to texture every frame, I guess you are looking at the Source (Blue) Portal in the video.
The Source Portal renders the Destination Portal Perspective, so moving the Source Portal does not change its texture.
Moving the Dest Portal changes the Source texture, so watch when the Red Portal moves. It updates every frame.
I think I understand what the problem is. You're not taking the camera position into account when rendering the portal, is that right? That's not how portals work. But maybe you didn't do that for performance reasons so you can cache the texutre? It should look like this: https://www.youtube.com/watch?v=7yirayL-x88
My first idea was to render a blended poly ( quad sprite ) on top of the portals render-to-texture, to create the border.
But that seemed too boring, so I created that effect by overlaying multiple rotating sprites in different directions, with different speed and depth to create a volumetric 3D effect.
Nice idea to make it look vollumetric that way!
Why is a rectangle visible beneath the portal sometimes though (especially during movement)? It seems to lag behind the border.

By the way have you thought about implementing texture matrices or stencil masks for some effects yet? Texture matrices are trivial to implement (just transform UVs like vertex positions already), but stencil masks might be a bit difficult (probably need to use modifier volumes here..)
The latest build renders now renders everything in the scene from the Dest Portals perspective ( this includes the Source Portal, creating an infinite reflection, as well as the Player model )

Image
Beautiful! Keep it up :)
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
bbmario
DCEmu Freak
DCEmu Freak
Posts: 88
Joined: Wed Feb 05, 2014 5:58 am
Has thanked: 9 times
Been thanked: 3 times

Re: Quake 3 lightmaps - PVR Multi-Texture

Post by bbmario »

Is the multi-texture BSP loader code on github or KOS SVN?
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: Quake 3 lightmaps - PVR Multi-Texture

Post by PH3NOM »

bogglez wrote:Hm, not sure whether it's worth abandoning GL for that.
Thanks again for your consideration! I am not abandoning GL 8-)
DCE API was made to see how far I can push the DC, without conforming to the constraints of any specific API.
It is not meant to replace OpenGL; it only performs a small set of critical functions and leaves the rest to the client to handle.
bogglez wrote:Wouldn't it be easier to add a define that controls whether the passes may be mixed or need to occur in the PVR's native order? So once blending has been activated it's not possible to submit opaque polygons anymore (or they'll get rendered with blending on but set to opaque). That would also remove the vertex buckets for the different modes, but still allow using GL instead of a new API.
Yeah, for OpenGL my idea is to submit the OP vertices directly and buffer only the TR polys.
This would maintain OpenGL spec while reducing the buffer size by 1/2.
bogglez wrote:I think I understand what the problem is. You're not taking the camera position into account when rendering the portal, is that right? That's not how portals work. But maybe you didn't do that for performance reasons so you can cache the texutre? It should look like this: https://www.youtube.com/watch?v=7yirayL-x88
Right.
That build uses the portal surface normal for the look-at matrix of the render-to-texture.
The code has been updated to use the reflection vector of the player position to the portal position against the portal surface normal for the look-at matrix of the render-to-texture.
Keep in mind that normally, each portal would render the opposite portals perspective, but this would need 2x render-to-textures per frame ( ~15 fps with KOS ). So instead, I only render-to-texture the destination portals reflected perspective, and use that texture for the source and dest portals base texture.
bogglez wrote:Nice idea to make it look vollumetric that way!
Why is a rectangle visible beneath the portal sometimes though (especially during movement)? It seems to lag behind the border.
By the way have you thought about implementing texture matrices or stencil masks for some effects yet? Texture matrices are trivial to implement (just transform UVs like vertex positions already), but stencil masks might be a bit difficult (probably need to use modifier volumes here..)
Thanks! The hard part is rotating the vectors in a direction that is coplanar to the cross product of the surface normal and the relative computed up or right vector, dependent upon the possibility of the up vector being coplanar with the surface normal. I still need to work out a few cases to support the effect rendered on any surface normal.
I considered texture matrices, but they cant help for what I am doing here. Like you said, should be trivial to add to OpenGL.
Stencil masks, although not helpful here, could be interesting for shadows and such. Again, that would take a considerable amount of work to implement.
bbmario wrote:Is the multi-texture BSP loader code on github or KOS SVN?
Thank you for the interest!

Things are currently closed-source. I will likely release a striped down version that is the simple render code for a GL example in the future. Stay posted!
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: Quake 3 lightmaps - PVR Multi-Texture

Post by PH3NOM »

Bump, back in progress.

I have been able to load some larger maps with the new API.
Image

Image

Oh yeah, added models support to the engine, with world collision, for AI entities.
Image

Without multi-texture, we are at 60fps.
The PVR hardware does not support multi-texture, so no matter what approach you use in software, 2x vertices need to be submitted to the PVR.
Image
Post Reply