Official forum of the Irrlicht Engine
https://irrlicht.sourceforge.io/forum/
Aha, interesting approach (gamedev articleBlindSide wrote:...
?). Never tried that way, myself. High quality stuff, I must say - very excellent job.
), but only when John Carmack re-affirmed its possibility in his QuakeCon speech that I took it into further serious consideration. (All he said was "Dont use cubemaps, they have sucky support, stick everything on a big texture instead.")
... also, how is your atlas organized (which direction goes where)? I appreciate any sort of description 
agi_shi wrote:Interesting. Can you explain the texture coordinate generation for the virtual cube map more in depth? I take it you use the vector from the light to the point being shaded (well, for omni light shadow mapping, that is)? Any specific code you can show (reason is, won't the final coords be "warped" by the 90 fov perspective)? I'm not really interested in code as much as a good, wholesome description
Haha the short answer is, not very. I just kept changing which viewport belonged to which camera until the correct textures fell into their places, I didn't really plan ahead which sides of the cube go where, though I should do it sometime to improve filtering. Press R in the demo to see the texture in fullscreen.how is your atlas organized
I'm not on my main coding computer right now, but it basically involves just general projective texturing with 3 cameras one for each axis, and inverting the Y coord of the uv if the pixel happens to be in the negative direction. In essence they are, and should be warped by the 90 degree FOV, if it was orthogonal projection then this just wouldn't workAny specific code you can show (reason is, won't the final coords be "warped" by the 90 fov perspective)?
You can see how the texture bends and stretches when you throw the cube, I find it very interesting behavior, but the shadow mapping tests look ok so I'll assume its supposed to do that. At first I used another method which is to test the area of each cameras projection (Just the general saturation test), which is nice because it allows me to rotate the cubemap projection but it showed artifacts at the seems. The new method is cleaner requires me to perform a rotation on the coordinates to match the cubes rotation first.Yeah, I took the recommended route of recording the distance from the light in the shadow map instead of the clip coordinates Z position. I'm not sure if this is necessary, but it works. Note I packed this into RGBA channels for 32-bit accuracy. This method makes it hard to judge your boundaries though, as theres no "FarValue" to divide by, you just have to guess a constant number for the current scene (Or the light's range?).I take it you use the vector from the light to the point being shaded (well, for omni light shadow mapping, that is)?
Interesting. I was thinking of getting the direction from the light to the point being shaded (like a usual cube map solution), and basically emulating texCUBE. I could get the actual texture coordinate as texCUBE does it, and then move it over on the X axis based on which face I needed to sample from (if I were to organize the atlas as +X -X +Y -Y +Z -Z). Another thing, which seems to do what that NVidia demo you mentioned seems to do, is just use a texCUBE to get my 2D coords, which can be prebaked such that I don't need to move/calculate anything other than the usual shadow mapping.BlindSide wrote:agi_shi wrote:Interesting. Can you explain the texture coordinate generation for the virtual cube map more in depth? I take it you use the vector from the light to the point being shaded (well, for omni light shadow mapping, that is)? Any specific code you can show (reason is, won't the final coords be "warped" by the 90 fov perspective)? I'm not really interested in code as much as a good, wholesome descriptionHaha the short answer is, not very. I just kept changing which viewport belonged to which camera until the correct textures fell into their places, I didn't really plan ahead which sides of the cube go where, though I should do it sometime to improve filtering. Press R in the demo to see the texture in fullscreen.how is your atlas organized
I'm not on my main coding computer right now, but it basically involves just general projective texturing with 3 cameras one for each axis, and inverting the Y coord of the uv if the pixel happens to be in the negative direction. In essence they are, and should be warped by the 90 degree FOV, if it was orthogonal projection then this just wouldn't workAny specific code you can show (reason is, won't the final coords be "warped" by the 90 fov perspective)?
You mean byte RGBA? Interesting approach. Too bad I can't try this myself - I need a few floating values, which forces me into RGB/RGBA which 16 bits for each channel. I actually use full 32 bits per channel for high end machines (8800+).Yeah, I took the recommended route of recording the distance from the light in the shadow map instead of the clip coordinates Z position. I'm not sure if this is necessary, but it works. Note I packed this into RGBA channels for 32-bit accuracy. This method makes it hard to judge your boundaries though, as theres no "FarValue" to divide by, you just have to guess a constant number for the current scene (Or the light's range?).I take it you use the vector from the light to the point being shaded (well, for omni light shadow mapping, that is)?
No problem. I know what it feels like - I promised an Ogre soft shadowing demo with non "ExampleApplication" code, and am yet to release itI'm sorry for taking so long with that shadowmapping demo, I've been very busy lately and I don't want to release something thats rushed or unpolished.
Cheers
Good luck, so far your stuff looks excellent!Well I already told you I couldn't use the NVidia one because Irrlicht does not have cube mapping support, so where the hell do I get that texCUBE from?agi_shi wrote: Interesting. I was thinking of getting the direction from the light to the point being shaded (like a usual cube map solution), and basically emulating texCUBE. I could get the actual texture coordinate as texCUBE does it, and then move it over on the X axis based on which face I needed to sample from (if I were to organize the atlas as +X -X +Y -Y +Z -Z). Another thing, which seems to do what that NVidia demo you mentioned seems to do, is just use a texCUBE to get my 2D coords, which can be prebaked such that I don't need to move/calculate anything other than the usual shadow mapping.
OGRE already has point soft shadowing built in, it even has LiPSM right?agi_shi wrote: No problem. I know what it feels like - I promised an Ogre soft shadowing demo with non "ExampleApplication" code, and am yet to release it
heheheI know that. I was simply stating my approachBlindSide wrote:Well I already told you I couldn't use the NVidia one because Irrlicht does not have cube mapping support, so where the hell do I get that texCUBE from?agi_shi wrote: Interesting. I was thinking of getting the direction from the light to the point being shaded (like a usual cube map solution), and basically emulating texCUBE. I could get the actual texture coordinate as texCUBE does it, and then move it over on the X axis based on which face I needed to sample from (if I were to organize the atlas as +X -X +Y -Y +Z -Z). Another thing, which seems to do what that NVidia demo you mentioned seems to do, is just use a texCUBE to get my 2D coords, which can be prebaked such that I don't need to move/calculate anything other than the usual shadow mapping.
You mean point light soft shadowing? No. Heck, it doesn't even have spot light soft shadowing. It doesn't even have point light texture shadowing. It does support (a non-broken impl.OGRE already has point soft shadowing built in, it even has LiPSM right?agi_shi wrote: No problem. I know what it feels like - I promised an Ogre soft shadowing demo with non "ExampleApplication" code, and am yet to release it
) point light stencil shadows (and texture shadows for spot lights), if that's what you're confusing it with . It also has various camera setups, like the LiPSM that you mentioned. I don't like it though, I set up my camera the right way I'd say vice-versa, but then I'd start an Ogre/Irrlicht war with an Irrlicht developer that is interesting to talk toPS: Irrlicht rules, OGRE drools
Cheers
I wonder which one that would be, because none of the dev team members ever participated actively in such discussions.agi_shi wrote: I'd say vice-versa, but then I'd start an Ogre/Irrlicht war with an Irrlicht developer that is interesting to talk to
hybrid wrote:I wonder which one that would be, because none of the dev team members ever participated actively in such discussions.agi_shi wrote: I'd say vice-versa, but then I'd start an Ogre/Irrlicht war with an Irrlicht developer that is interesting to talk to
agi_shi if you continue that way I won't let the procedural spiders go through your portalsagi_shi wrote:hybrid wrote:I wonder which one that would be, because none of the dev team members ever participated actively in such discussions.agi_shi wrote: I'd say vice-versa, but then I'd start an Ogre/Irrlicht war with an Irrlicht developer that is interesting to talk to
You made the spider things?!agi_shi if you continue that way I won't let the procedural spiders go through your portals
No don't lock it, nothing bad will happen. In fact, good will happen, if I have more questions of virtual cube maps. Because I can't find any other good, active discussion of them.BlindSide wrote:I'm locking this incase something bad happens.
EDIT: I can't lock my own thread? Oh noes..
You made the spider things?!agi_shi if you continue that way I won't let the procedural spiders go through your portals
No, obviusly I didn't.BlindSide wrote:I'm locking this incase something bad happens.
EDIT: I can't lock my own thread? Oh noes..
You made the spider things?!agi_shi if you continue that way I won't let the procedural spiders go through your portals
.) It is a dangerous for humanity and universe. :lol:I see. Ok.Vsk wrote:No, obviusly I didn't.BlindSide wrote:I'm locking this incase something bad happens.
EDIT: I can't lock my own thread? Oh noes..
You made the spider things?!agi_shi if you continue that way I won't let the procedural spiders go through your portals
I am just kinding, I was mading when a father get angry with his sons and try to punished him. But obviously it was not very clear
And obviuly I am not fithning with anyone, I like agi_shi portals, and I love becaue he is young and take too seriouly everything we say
(But the portals collapse into a neutrin star
Code: Select all
+------+------+
| posx | negx |
+------+------+
| posy | negy |
+------+------+
| posz | negz |
+------+------+
Code: Select all
+------+------+------+------+
| | posy | | |
+------+------+------+------+
| negx | posz | posx | negz |
+------+------+------+------+
| | negy | | |
+------+------+------+------+
I agree... which is why I decided to post here and not PM himagi_shi wrote: No don't lock it, nothing bad will happen. In fact, good will happen, if I have more questions of virtual cube maps. Because I can't find any other good, active discussion of them.