DYNAMIC SHADOWS RENDERING.
#1
Posted 06 October 2016 - 01:25 PM
What determines whether or not a shadow is displayed on a shape? A static object like a train platform for example.
de_ELOldSta_spec_Platf.S shape won't show a dynamic shadow that is cast on it by the tree out of sight to the right.
There is what appears to be some sort of shadow near the lamp post.
It's only the join point between two platform sections and also the fence railing should be casting it's shadow on the platform.
Is there something in the shape file I should look for?
And also: What determines whether or not a shape casts a shadow?
regards,
vince
#2
Posted 06 October 2016 - 01:32 PM
#3
Posted 06 October 2016 - 01:56 PM
Generating any kind of realistic imagery is VERY VERY VERY difficult. In all simulations you MUST make the effort being in the sim as it will always be to much to difficult to create true to life scenes.
Hope this makes sense, if anyone has any questions please ask.
Lindsay
#4
Posted 06 October 2016 - 02:09 PM
http://www.opengl-tu...shadow-mapping/
It is true that the scene has to be rendered at least twice.
#5
Posted 06 October 2016 - 05:13 PM
disc, on 06 October 2016 - 01:32 PM, said:
http://www.elvastower.com/forums/public/style_emoticons/default/sign_sorry.gif about responding so late.
I quite simply forgot as I am working hard to get the Long Island Rail Road route ready for the Public Beta release. Route editing is done but some of the activities out of the 18 in total are giving me fits.
That aside, here are two pictures and a clip of the 2 shape files in question.
One renders shadows correctly while the other does not.
Attached two pics and a text of the top of both shape files.
MSTS ROUTE EDITOR
OPEN RAILS
OR view distance set to 2 kilometers.
The only difference I see in the shape files beside the shape itself is the shader_names line.
The one that does not show shadows has BlenATex while the one that shows shadows has TexDiff as named_shader.
THIS IS THE PLATFORM THAT DOES NOT SHOW A SHADOW CAST UPON IT. de_ELOldSta_spec_Platf.s SIMISA@@@@@@@@@@JINX0s1t______ shape ( shape_header ( 00000000 00000000 ) volumes ( 1 vol_sphere ( vector ( 0.0334625 0.573157 1.43051e-006 ) 12.8977 ) ) shader_names ( 1 named_shader ( BlendATex ) ) texture_filter_names ( 1 named_filter_mode ( MipLinear ) ) points ( 34 point ( -12.5876 0.657064 2.52 ) point ( -12.5876 -0.269036 2.52 ) point ( 0.0123811 -0.269036 2.52 ) point ( 0.0123811 0.657064 2.52 ) +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AND THIS IS THE PLATFORM I MADE IN GSU THAT DOES SHOW A SHADOW CAST UPON IT. LIRR_Platform_Employee_50m.s SIMISA@@@@@@@@@@JINX0s1t______ shape ( shape_header sketchup11 ( 00000000 00000000 ) volumes ( 1 vol_sphere ( vector ( 0 0.435 24.5 ) 25.0552 ) ) shader_names ( 1 named_shader ( TexDiff ) ) texture_filter_names ( 1 named_filter_mode ( MipLinear ) ) points ( 16 point ( -1.5 0.9 -0.5 ) point ( -1 0.9 49 ) point ( -1.5 0.9 49.5 ) point ( 1.5 0.9 49.5 ) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
best regards,
vince
#6
Posted 06 October 2016 - 11:27 PM
Goku, on 06 October 2016 - 02:09 PM, said:
http://www.opengl-tu...shadow-mapping/
It is true that the scene has to be rendered at least twice.
I agree that its not true colliision detection on the 2nd pass, but the Z buffer is checked for every pixel to see if something is between it and the light source and therefore the pixel is in shadow, this means its just another thing for the GPU to do.
You see I cut my teeth on computor game graphics by writing (In Motorola M68K assembly language) many years ago a very fast game routines library for others to use, for instance the bit blit routine could handle areas 2 to 8 pixels wide (we are talking 16 colours here, this was in the early 1990's) and from 4 to 32 lines deep and had only ONE conditional test in the whole 108kilobytes of the final assembled routine, this routine was 20 times faster than the existing bit blit routine due to its "inline" nature (ie no loops). As a consequence I still look out for any possible unnecesary processing.
#7
Posted 16 October 2016 - 10:06 AM
#8
Posted 16 October 2016 - 10:16 AM
#9
Posted 16 October 2016 - 01:21 PM
Genma Saotome, on 16 October 2016 - 10:06 AM, said:
As it currently stands, everything which casts a shadow must be rendered 5 times - once for the screen, and once for each of the 4 shadow maps. The shadow map rendering isn't the same level of CPU or GPU work as the screen rendering (the shader is much simpler, for example) but it's still 5x the draw calls. So it increases CPU and GPU similarly. There should be ways to optimise this with e.g. multiple render targets, but they've not been investigated yet.
Note that what receives shadows has little to no effect on rendering effort (it costs a tiny bit of GPU and no CPU).
#10
Posted 16 October 2016 - 03:39 PM
James Ross, on 16 October 2016 - 01:21 PM, said:
How unfortunate. Yet another reason to hope the OR code can successfully make its way to multi-threaded rendering.