Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / Vertex line of sight???

Author
Message
Daryn Alsup
16
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 9th Jun 2009 14:32 Edited at: 9th Jun 2009 14:44
Okay so here is my dilemma. I have a solar system made of a sun sphere, a planet sphere and a moon sphere. What I need and have had no success completing myself is something like this:

... code ...
Vertex line of sight to sun from planet
heat= heat + ambient light% + solar heat/ solar distance + ...
... code ...

The point of the line of sight from a vertex is to determine when the suns heat is at it's greatest (if the suns 'light' is reaching the surface.) What I haven't been able to figure out is how to tell my app not to 'shine' through itself - since the line can only be drawn from an object to an object. How can I create a line from each vertex on the planet sphere to the center of the sun sphere while detecting collision within itself (from the planet's vertexes to the planet's poly's) and the moon sphere? If the collision equals zero, I could then use the vertex numbers not participating in the collision to calculate the heat generated by the planet. Anyone? I am so lost with this one.

The picture attached shows you what I mean if i was too confusing

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.

Attachments

Login to view attachments
Math89
20
Years of Service
User Offline
Joined: 23rd Jan 2004
Location: UK
Posted: 9th Jun 2009 15:12
If you need something really accurate (e.g. mountains can cast shadows), you could use sparky's collision dll but this will obviously be slow.
Otherwise, what about a simple dot product? This is what is used for basic light calculations and backface culling. In your case, you need find the normalised vector going from the sun to your vertex, and your vertex normal. If dot product will return a float between 1 and -1, A positive number means that it's facing the light, a negative number means that it should be in the shadow. This means that you can know easily when the sun effect is at its greatest by seeing how close to 1 is the result.
Dot product :
d = x1*x2 + y1*y2 + z1*z2


If you want efficiency and quality, you could use both methods:
calculate the dot product, and, if the result is positive, do the raycasting test for adding shadows.
Daryn Alsup
16
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 9th Jun 2009 15:20
Well this for all intensive purposes is only for the calculation or heat and climate. Because I cannot tell the app when the sun is shining and when it isn't, I cannot tell the planet 9and its many surface types when and where the heat should rise or fall.

Gathering the summer's heat average and winter's low would be done automatically with the right equation between solar output, heat to radiation-radiation to heat conversion and solar distance from the planet. So basically I am asking for a way to draw many lines from all vertexes on a sphere to another sphere. If the sphere's lines collide with it's inner faces (polys) then it is "the dark side" of the planet.

The only problem with the dot product is that it can also = 0. Is this mid light? is this mid dark, how can I tell the planet that one side is losing light and the other gaining? More questions without a quick answer... oh look now I feel like a programmer

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
Math89
20
Years of Service
User Offline
Joined: 23rd Jan 2004
Location: UK
Posted: 9th Jun 2009 15:30
0 means that light has no effect. So if the result is 0 or below, you are on the dark side of the planet.
But there is something you should keep in mind: if you calculate the light vector from the vertex and sun positions, it means that you assume that the sun is a small point. If you calculate the vector from the planet and sun positions, then it means that you assume that the sunlight rays are parallel (which might be what you want, since the sun is supposed to be very large and far).

The only way to say that one part of the planet is gaining light would be to know in which direction it rotates and do another dot product on a slightly rotated position. If the new dot product is higher than the first one, then, this point will gain some light soon.
I'm sure there is a more efficient way of doing it, maybe by comparing the angle between the sun and the centre of the planet and between the sun and the vertex. Then, if you are processing a vertex on the lit side, when the difference between those angles is getting smaller, you are gaining light.
I don't know which one of these methods is the best, but it can give you some ideas.
Daryn Alsup
16
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 9th Jun 2009 15:34
Hey that works real nice. I'm gonna give this a try. Out of idle curiousity, if say, the sun and planet have a moon between them, what would be the best way to tell the temperature not to fall as it isn't the dark side of the moon? Or is this where we part

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
Math89
20
Years of Service
User Offline
Joined: 23rd Jan 2004
Location: UK
Posted: 9th Jun 2009 15:43
I'm not sure I really understand the problem. Do you want shadow of the moon to cast a shadow on the planet, or do you want to minimize its impact?
If you want to take the shadows in account, you need the raycast, but if you want to make sure that the part shadowed by the moon isn't as cold as the dark side of the planet, then it becomes a bit harder. In reality, objects would tend to accumulate and release the heat, so maybe you could say that each vertex has its heat value which increases when it's lit and decreases when it's in the shadow. This would prevent your planet for freezing when it's shadowed by the moon for a few seconds only.
Daryn Alsup
16
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 9th Jun 2009 15:54
No you got it... and I beat you to the answer j/k there is a planet offset of normal heat added to luminous heat. now to tell this stretch of code which areas of the sphere are water and not water... insert evaperation code here and wala: moisture in the air then a little convection... some particle commands and poof! weather!

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
Daryn Alsup
16
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 10th Jun 2009 08:20
Okay I hit a road block. Maybe you know the answer and for reference I did true set object texture. What I did to ensure the code was properly utilized was use the set vertexdata diffuse commands to set the side with light in red and the side in dark blue. I get this weird line half red half blue with black down the middle. If it were a texture it would appear as though the texture was not tiled. But because this is using Diffuse to color the object via vertexes, how can I get rid of this? And I am aware it is completely off the topic of my thread

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
Math89
20
Years of Service
User Offline
Joined: 23rd Jan 2004
Location: UK
Posted: 10th Jun 2009 12:13
Can you post a screenshot? Because I'm not sure what your problem looks like.
Daryn Alsup
16
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 11th Jun 2009 05:07 Edited at: 11th Jun 2009 08:12
Okay i figured it out. The line has to do with the Object FVF. I've got the right idea with the code I know I do, but I think I am missing something



What am I doing wrong? oh and not to insult any one other than myself but I am truly a complete blond... with the roots to prove it LMAO.

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
Daryn Alsup
16
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 11th Jun 2009 09:47
Hey I updated the post

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
Math89
20
Years of Service
User Offline
Joined: 23rd Jan 2004
Location: UK
Posted: 11th Jun 2009 13:11
There were various errors. The first one, which caused the strange line was due to Set Object Normals, which seems to dislike spheres.
The most important problem couldn't be seen on your demo, but actually, the vertex data uses local coordinate. This means that for all your calculation, it was assumed that your planet was placed on the sun and not rotated. I fixed that using some matrix calculation to turn a local space coordinate into a world space one. However, it requires the IanM plugins : http://forum.thegamecreators.com/?m=forum_view&t=85209&b=18 (I strongly recommend them, there are a lot of useful functions).




Don't worry if you don't really understand all this matrix stuff. What you have to remember:
- for changing a coordinate (e.g. the vertex position) from local to world space, you need to make a vector4 with the positions in the 3 first components and a 1 in the last one, to get the object matrix (which holds the positions, rotations and scale), and finally, you have to transform the vector with the matrix.
- for changing a vector (e.g. the vertex normal), you need to do the same but with a 0 in the last component of your vector.
- for changing a vector or a coordinate from world to local space, do the same but inverse the matrix.
Daryn Alsup
16
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 11th Jun 2009 14:24
Oh TY so much. More then just a few errors lol. but thank you. <<<take bow here! take bow here! take bow here!>>> I will post the weather strip code here in a few days... or hours if I get some coffee Ty once more.

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
Daryn Alsup
16
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 11th Jun 2009 16:37
Not that I am being picky or anything... but did you notice the "drawing black line" in between the red and blue? what do you think this line is formed from?

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.
Math89
20
Years of Service
User Offline
Joined: 23rd Jan 2004
Location: UK
Posted: 11th Jun 2009 17:05
If you mean the smooth dark green line, it's just because of the way I decided to shade the vertices.
If you want a full blue and full red with no gradient, you can change the colouring part with this:

But in my opinion, it doesn't look that good.
Daryn Alsup
16
Years of Service
User Offline
Joined: 5th Jul 2008
Location: In your head... dun dun DUN!!!!!!!!
Posted: 11th Jun 2009 17:19
No you're right in everything you've posted... and that green line looks great... but after the green line reaches its highest intensity a black line is then drawn after it so a new green line can be drawn from its lowest intensity. Look at where the green line is drawn and you'll see the change in face color... it is more appearant when you change the backdrop color to "22"

Jack and Jill went up a hill to fetch a pale of water... but Jill got tired of his s#%& so she shot him.

Login to post a reply

Server time is: 2024-11-24 06:04:55
Your offset time is: 2024-11-24 06:04:55