This is extremely interesting. I knew Graal was capable of rendering polygons, but I never imagined someone would actually accomplish this much with the client ever. Sir, this is by far the greatest thing I have ever seen scripted by a single man. You said you plan on making this public, yes?
Is there a plan to make this a third person camera, or would you have it as a first-person camera? I could easily see someone using this to create some sort of death-match game like DOOM. This adds a whole new level of possibilities to what kind of playerworlds or events people can create.

Also are those reflections just Photoshopped or did you really script that? Looks gorgeous, man. :D

PFA did all of the new 3D scripting, he gets the credit :)

And the reflections are all scripted ;)

My hat goes off to both of you, then.
Solid work. This is exactly the innovation Graal needs.
Seriously, it's relieving to see such dedicated people creating such a revolutionary idea on the client and making it a reality. Again, that is simply amazing and really pushes past what we thought was the limits of the program. :D

That is amazing.

Is it creating the reflection only initially or constantly refreshing. If it is constantly refreshing I thought that'd be rather intensive, no?
Also, does this have any lag overall as of yet?

Reflections are all real-time. Intensive? Not really, running fine on my computer(20fps). Quality can be adjusted, lowering the quality will create distortion in the textures, but still mostly playable.

Here, see a video :)



Chances are in final play the scene won't be that zoomed in on the terrain, though.

Oh neat, I see what you did there. Seems very smooth as well. Well done, can't wait to mess around with the code.

The horizon renders much further than that in a mode7 racer. Not to be a killjoy, but this is just as far as everyone else gets with mode7 in Graal. The hump has been getting enough texel density to accurately render things further out on the horizon. I think with the new technique you're using it'll be totally possible, though. Best of luck.

looks awesome.

"Chances are in final play the scene won't be that zoomed in on the terrain, though."
http://i.imgur.com/jpojQ.png
Actual racing levels will probably be gmaps, alleviating this issue moreso.

yeah, I know what you said. I'm just saying as you approach the horizon you have to do more texel samples in order to accomplish the desired effect.

This might not be an issue for you since you can cheap out by just having the GPU do its built-in texture interpolation because you build an image.

I'm also not sure what method you're using, but mode7 isn't a 3D transformation or projection. It's a 2D affine transformation, which is why there's a clearly defined (and perspectively inaccurate) horizon line that appears. If you are doing a 3D transformation, you should just drop it and use the actual formula. It's on Wikipedia in the form of an affine transformation matrix. It'd probably make it very easy to replicate the mode7 results pretty much perfectly.

I was having a bit of trouble messing around with PFA's version, since it's not something I wrote up so I was fairly unfamiliar with it, and decided to revisit my own to see where I get.

I'm pretty happy with what I eventually ended up with:
http://i.imgur.com/89JkU.png

live demo? ;D

Are you having framerate issues? I see the 3 and have some ideas.

I cranked up the quality to 1 polygon per tile simply to make it look nice :) Here's at 16 tiles per polygon:
http://i.imgur.com/y2sdr.png
There's more distortion because of the extreme angle, but honestly I'm okay with that. People with more powerful computers will be able to adjust the quality.

Anyone who has access on Testbed can go on and add "Public/DustyPorViva/Mode7" Though I'm still changing things around so don't be surprised if it's not working at any given time.

Does it bottleneck during rasterization or transformation with the higher quality?

You could also probably get away by scaling up the polycount for the closer sections.

I was curious and checked it out before. Simply running the loop at 64*64 with no math or rendering drops the fps down to about 8. Then the math/rendering drops it down to 3.

I was thinking about the scaling resolution as well, but that may be WAY too much work.

I so want to play around with that code. Really good job on it so far! :D

Let me play with it ;)

Wait, no math or rendering as in a 64x64 loop without transformation or rendering? What else are you doing? It sounds like something odd is going on if you're getting significant performance drops from things other than what should most intensive parts.

Unless I'm misunderstanding what you meant by math and rendering, of course.

Putting each polygon on its own layer, or at least ensuring neighboring polygons don't have the same layer should prevent Graal from trying to sort them. Normally Graal sorts images by their bottom left corner, which, at least on some of the older clients, caused huge performance drops because it was done every frame without regard to the previous frame (It should store the new, sorted data so the majority of the stuff is still sorted).

Dynamically scaling up would drastically increase performance and visual quality..

My mistake, it was disabling everything other than the polygons. I ran a 64*64 loop and only displayed polygons, with nothing else going on in the loop, and that's what caused the massive slowdown. Even without textures applied. I will have to try the layer thing, but I doubt it would make much of a difference in extreme cases. The fact that I can render an entire level with this perspective with no slowdown(while only have some minor visual distortion), is quite an accomplishment in Graal, imo.

If that's the case, then it's very likely that Graal renders scripted images and polygons into their own draw call. The bottleneck here is the communication between the CPU and GPU taking too long because the CPU has to upload data to the GPU, and wait for it to return before it can push the next polygon, etc. Normally, the CPU uploads it all at once which is significantly quicker.

Because of this, the only way to increase performance here is to use less polygons to reduce the amount of draw calls between the CPU and GPU.

I wonder.. is there a way to render the entire scene with just one, massive polygon? It would be possible if you can manipulate the UV coords independently of the vertex positions. If you could pull that off, your performance would literally skyrocket.

You can, yes, however Graal doesn't map textures correctly. It will break on the diagonal seam(which is also what is causing the distortion with current rendering). That's why I had to resort to using multiple polygons, to break that seam issue.

Oh, and also even if you use one polygon, you can't emulate distance with it.

Why not?

Because you can only apply one texture to a polygon, and you'd need the have the Y scale of the image vertically get smaller towards the horizon. At least, that's how I figure. Either way Graal doesn't like skewing textures on polygons.

If you can set the UV coords independently from the vertex positions like I said earlier then you can do the exact same thing you're doing now with a single polygon. How do you set the UV coords?

I don't think you can. Regardless, this is what it looks like when you apply an image to a skewed polygon:

http://i.imgur.com/9g8Ym.png

The issue was brought up with Stefan a long time ago, but I don't think it will ever be fixed.

Dat GraaLSD :noob:

You said it an earlier post you could :/

Anyway, if you can't set UV coords independent of their vertex positions, then the only increase in framerate that'll really help you is reducing the amount of draw calls. In your case that pretty much means the only thing you can do is reduce the amount of polygons. You should really scale the quality up from high to low as it approaches the horizon, though, with this technique it's the only room for speed improvements as far as I can tell.

I misunderstood, but no I don't think you can mess with UV coordinates.

As for the quality, aye I have considered having near polygons larger, but that would involve a lot of core rework. Also, the problem with that is in order to better imply the distance of the ground towards the horizon, it also needs a decent polygon count.

I'm not really stressing over it. I don't run an awesome rig so anyone with decent gamer towers can probably run it at a 2:1 tile to polygon ratio.

Managed to get this much done just before bed. Finally implemented rendering gmaps. It's still a bit buggy(some levels seem to not be rendering, some divide by 0 issues with some polygons), but I'm very glad I got past that hump.

I must say Dusty, this is really good, extremely impressive, but I do have one small question.

Do you plan to allow certain tiles to stand up with this (of course once you've worked out any bugs like you've mentioned)?
Example: Trees or fence tiles, or house tiles.

Nice work, but the transformation is still quite off. The scene should see more distortion toward the top in the way of shrinking horizontally. Also, the horizon line isn't appearing properly.

This is quite interesting. Will we finally see a Graal 3D? :)

Does that look 3D to you? :oo:

fixed.

Tiles? No. But NPCs will be rendered onto the level to supplement that void.

Aye, there's probably a lot more tweaking that can be done, but getting past that gmap hump was my focus for now.

Well, that's what I was meaning to say, I should've stated that :p

Glad to hear it.

I can imagine going into a haunted house with "spooky" ghosts n stuff.

Looks cool, do you think there could be something special added in the engine to make it faster?

See: