Reading texture from PVR back into SH-4 RAM

[nymus]

MisterDave...

Dreamcast love is strong.

[BlueCrab]

Definitely a cool looking effect to see coming from some KOS based code. I haven't actually done much with anything 3D outside of what I had done in some Computer Graphics classes at the university (both at the undergraduate and graduate level), certainly not much with Dreamcast stuff in 3D. Too much math for my tastes.

As for the question of whether the current PVR code waits for a vblank or not when doing render-to-screen: I haven't changed anything related to the timing of frames or anything else like that, so it would be reasonable to expect that nothing has changed in that regard. Also, that little trick with making a twiddled texture by using repeated passes is kinda interesting too. Never actually thought about either of those two things.

[PH3NOM]

Looks like we are all learning something here, good stuff

Small bump, I have optimized my clip algorithm by outputting a 4-vert strip instead of 2 triangles of 6 verts, in the case that two triangles are output from the sliced triangle.

Anyway, yeah that screenshot looks cool! But I am curious how you will implement clipping for your project?

@Tapamn: Impressive as always my friend, dont hesitate to share your progress here!
Would you mind giving a brief of dot-3 bump mapping, aka "normal mapping" using the PVR?
1. How do we create the bump maps for the PVR ( i know height maps are like normal textures, except each color component represents an x,y,z value rather than a r,g,b value, but what format does the PVR expect? )
2. How do we submit the bump mapped vertices to the PVR? I believe there is a specific vertex type?
3. Are multiple light sources possible to implement with a single face? I think you mentioned that the color for each vertex in a face is uniform, kind of like how the PVR handles Quads, so id guess not...

[BlueCrab]

With regard to bumpmapping, there is a demo that was posted on the forums here long ago. Here's the post in question that links to it (and the links do appear to still work). It will not compile as-is against a current version of KOS, but that's probably only due to it using the old Maple API that was removed some time ago. Quickly perusing the code, it should at least compile and run other than that.

[MisterDave]

@PH3NOM Regarding the clipping I cheated a bit by basing the geometry on a tilemap and clipping based on the FOV. I am currently rewriting this to pull in geometry from Blender, etc so I will need to do proper clipping.

I really need to get more involved with your clipping code, but just have a quick question. Does this need to be called after each poly is submitted or is it just before the list is submitted to the PVR?

Thanks, Dave.

[PH3NOM]

Well it depends how your pipeline works if you want to do it per-mesh or per-list, but bottom line, the vertices must be clipped before submitting to the PVR.

In my algorithm, clipping is applied per triangle, so it needs a minimum of 3 vertices as input.
If a single triangle is sliced into a single triangle, 3 vertices (triangle) are output from my algorithm.
If a single triangle is sliced into 2 triangles, 4 vertices (triangle strip) are output from my updated algorithm.

Remember, the vertices are traditionally transformed into Clip Space, where clipping is applied to the vertices
http://http.developer.nvidia.com/CgTuto ... ter04.html

Vertices that survive the clip stage are then transformed into Window Space, and submitted for rasterization.

I hope that helps, let me know if that did answer what you needed to know...

[MisterDave]

@PH3NOM A quick question while looking through your code. I was just wondering how you deal with the camera transformation matrix? My thought is that in order to determine whether a vertex will pass behind the camera then the clipping algorithm would have to reverse everything pushed onto the internal matrix. Perhaps I am overcomplicating things

Thanks, Dave

[PH3NOM]

@PH3NOM A quick question while looking through your code. I was just wondering how you deal with the camera transformation matrix? My thought is that in order to determine whether a vertex will pass behind the camera then the clipping algorithm would have to reverse everything pushed onto the internal matrix. Perhaps I am overcomplicating things

Thanks, Dave

Hmm.

Well, first off, remember, that the "camera" never actually moves, rather the vertices around it.
Once the vertices are transformed, the camera will always be at 0,0,0

I very much suggest reading this book provided by nVidia
http://http.developer.nvidia.com/CgTuto ... ter04.html

The traditional concept is that you transform the vertices into Clip Space to apply clipping


I say traditional because there are other ways to do it. One method I have implemented is by transforming the vertices into World Space ( i.e. translate / rotate but no perspective transform ) and then you can use the actual position of your camera from/to vectors.
If you rotate the camera to vector about the camera from vector by 90 degrees, this will create a line segment that represents a plane that lies perpendicular to the camera, i.e. the clipping plane.
From there, I measure the dot product of the vertex position to the camera from vector against the camera from/to vector.
If the dot product is greater than 0, the vertex in question lies inside the clip plane, 0 is on the clipping plane, less than zero means the vertex in question lies outside the clip plane.
Talk about over-complicating things

And how are you transforming your vertices? Through parallax? I have not used that much, but you will need a way to access the different matrices that combine the final transform, i.e. modelview, projection, etc.

[MisterDave]

Thanks PH3NOM for the link to the Nvidia material - It will do me a lot of good to get to grips with the chapter as a matter of principle then work properly through your code and notes. 

The vertices in my case have been transformed using Parallax.
I get the impression that Parallax is typically used for 2D where as KGL is typically used for 3D projects (plus the portability), so there is a tradeoff for me to make. Whilst KGL doesn't have render to texture support, I wonder if I can add in a mix of PVR+KGL in the way that the Bubbles direct render example does. Will have to test this.

[BlueCrab]

KGL is just a wrapper over top of the normal PVR code, much like Parallax. It just automates more of the process for you than Parallax does.