Handling Rendered Layers
Blitz3D Forums/Blitz3D Programming/Handling Rendered Layers
| ||
| Currently I use a rather simple rendering of layers to make sure everything is setup correctly, however I was hoping to optimize... any help? It just uses global pivots to hold all the entities that should be rendered appropriately for that layer, then its cycled upon the Function RenderLayered(Tween#) - Using the Castle-Demos FPS setup for tweening. I can't but feel as though this could be compressed and stream-lined. I'm relatively new to any type of higher efficiency rendering methods.
Type RenderLayer
Field Layer,Order
End Type
Global SkyLayer.RenderLayer=New RenderLayer
SkyLayer\Layer=CreatePivot()
SkyLayer\Order=1
Global TerraLayer.RenderLayer=New RenderLayer
TerraLayer\Layer=CreatePivot()
TerraLayer\Order=2
Global PlayerLayer.RenderLayer=New RenderLayer
PlayerLayer\Layer=CreatePivot()
PlayerLayer\Order=3
Function RenderLayered(tween#)
Local count=1
Cls
CameraClsMode Camera,0,1
For Layer.RenderLayer=Each RenderLayer
If Layer\Order=count
ShowEntity Layer\Layer
RenderWorld(Tween#)
HideEntity Layer\Layer
Count=Count+1
EndIf
If Count>=3 Then Count=1
Next
End Function
|
| ||
| You don't need to worry about optimising this. An "outer" loop will have no measurable effect on performance no matter how ugly its logic is - the real work is still all being done by RenderWorld, and hiding large chunks of the scene in a single HideEntity call is about as efficient a way to split up render sets as you can get in B3D. While three calls to RenderWorld are less efficient than one for obvious reasons, there's no way you can really change that while still having the separate render passes, so don't worry about it. As far as efficiency goes this is perfectly fine. In terms of the actual logical structure though... I am baffled as to the purpose of the "count" variable (and by extension, the "order" field in the RenderLayer objects). Surely both order and count are implicit in the ordering of the list and do not need numbering? (since it's logically impossible for two layers to have the same position - only one can be rendered at a time) What's supposed to happen if the list is ordered a different way? Things will be skipped, but not rendered later on as there is only one pass. And what is the significance of the counter being forcibly reset after three? |
| ||
| Tbh I honestly added the counter because of an apparent issue where it just wouldn't render them layered at all. It would only count 1 pass rather than all three and so this was my rugged way of by-passing it for that moment in time. Perhaps if i flip-flop the order of creation they'd be simply handled by the for - each loop in the proper order? The issue is the rendering scheme is completely screwed up without it, if i run through the function once, though it should loop 3 times. It would display the latest created layer first rather than presenting them all beautifully compiled together which was the sole purpose of the counter.(With Counter)--> Pass 1: Render Sky Stuff, Pass 2: Render Terrain Features etc., Pass 3: Player things so nothing clips through and i cant seem to accomplish this without the counter. (Without Counter)--> Hurr-durr Pass 3: Player things. Nothing else. Also its important to note that i was experimenting at the time with different rendering views. So that each one could be manipulated on the fly and with ease rather than having to change source code every time i wanted to see one effect. Just lemme know if I sound somewhat borderline idiotic, i'm rather new to rendering techniques and doing things associated with it often void me of any sleep at night. |
| ||
| Well if that's what it takes... I can only assume there's more going on somewhere else in the code that's interacting with it in an unexpected way because that count code, as presented, shouldn't be having any effect (reasoning through your smaller example above: every count test should match and the reset variable is never tested again; in that example they should be going through the loop in the order they are created). I'd suggest the old line-by-line commenting technique to see what you can get away with removing... I mean if it works as it is, it's presumably not a problem since you're unlikely to add more layers to the current game anyway by the sound of it... but the knowledge that a flaw is there would really nag at me in your position. Remember that you can reorganise a list at any time using Insert, so you don't need to rely on specifics of how it was created to set the order. |
   |