My two demos to participate on the contest, good luck to all!
I find the dice demo shows a few things I tend to find a bit jarring. First you have the perspective up very high (although likely necessary in this case to show they are actually in 3D), and it is obvious that you are rotating using a set transform, as the actual manner of the rotation is very specific to using separate angles combined each frame in a specific order. I’d suggest using a pair of vectors (up and side) and rotating them (or I could suggest quaternions but frankly… no, just no. They are so damn complicated - imaginary number theory can bugger off!) to get a much more natural effect.
The lighting and shadow one is very nice, but I’m surprised you didn’t add in the bump-mapping composite filter (not having looked at it myself, I’m not sure if it would easily handle multiple light sources so if you tried and it wasn’t capable of it, forgive me). One detail that doesn’t show up clearly in the vid but I just made out, so you get big props for it, is the fact you are doing soft lighting on the shadow edges - a small detail that really makes a big difference. Really nice!
@rakoonic I went trough a lot of trouble making these demos because I didn’t have much background in working with any kind of 3D, projections nor anything to do with a little more intense math than usual. Although these are fairly easy concepts to digest I faced a few problems that required hackish solutions. I intend to put the source of both projects inside the code exchange section but first I want to find optimal implementations for these so others don’t get confused with my own code riddles.
As you pointed correctly the perspective was wrong. I have changed that but I’m not sure if I understand the vectors rotation you suggest and actually I’m very interested in this because when dealing with rotation I faced a few problems to make spinning look in one direction. My attempts to do this failed because the gimbal lock problem (or at least I think so). As for the quaternions I have spent lots of time (still do) trying to understand (miserably) fully the math behind it. I guess I’ll keep pushing there since it seems to be a MUST to step inside the 3D world.
The light’s and shadow’s demo is actually going to change a lot because I have found too much troubles with the current implementation. One of them is that internally the shadows are not being casted properly to the edges but rather to the vertices and the performance is very poor to use in production. This was actually one of the reasons of why I didn’t push further with the bump-mapping although I’m definitely going to try it.
Here is the source:
https://www.dropbox.com/s/fa75c9g69qg24my/DiceRoller.zip
https://www.dropbox.com/s/yske0pbp28z1q0x/Shadows.zip
I appreciate your keen comments.
Ivan.
Your perspective isn’t wrong, it is just exaggerated - it has the same effect as looking through a fish-eye lens, or in a first-person shooter game, upping the field of view a lot. Imagine if those dice were instead big buildings, the perspective would be fine for them, but since we know they are small objects, it just comes across as a bit odd. The solution in this case is to move the dice further away from the camera, and increase the screen scaling (IE scale up values *after* you’ve done the perspective divide). As a simple example, the following two bits of maths would produce a similarly sized object on screen, but the first one would have a ‘stronger’ perspective effect (due to it effectively having a wider field of view) - assumes the object you wish to draw is centered around the origin so that doubling the camDistance does actually double the overall distance between you and the object:
[lua]local camDistance = 5
local screenScalar = 10
local screenX = ( obj.x / ( obj.z + camDistance ) ) * screenScalar
local screenY = ( obj.y / ( obj.z + camDistance ) ) * screenScalar[/lua]
and
[lua]local camDistance = 10
local screenScalar = 20
local screenX = ( obj.x / ( obj.z + camDistance ) ) * screenScalar
local screenY = ( obj.y / ( obj.z + camDistance ) ) * screenScalar[/lua]
This isn’t working code of course, I am just trying to show the interaction of the ‘camera distance’ modifier, and the ‘screen scalar’ modifier and how they interact to allow you to tweak the strength of the perspective effect.
In the second sample the object is twice as far away as in the first sample, so the perspective calculation would leave it at half the size - hence why the screenScalar is twice the value to compensate.
I haven’t got time now, but I’ll look into your code later on if I can. Thanks for the trust!
[EDIT]I meant to add, that as a first dip into the water of 3D, you certainly did well. And yes, gimbal lock is the problem you were experiencing where 2 axes collapse into the same orientation preventing rotation in certain directions. Quaternions really aren’t necessary - where I’ve needed free-form 3D I tend to do what I briefly described above (maintaining and manipulating a pair of axes and basing everything off of that), because it is just a lot easier to understand.
What you do is define an ‘up’ and a ‘side’ (+x) pair of axes, and you manipulate them.
It is easy enough to rotate these vectors by an arbitrary axis, and you can easily maintain their stability by renormalising them and using cross-product maths to ensure they stay at 90 degrees to each other. Then when it is time to draw your actual model with these axes, you get the cross product for the third axes, and use these three axes as multipliers for each point to align the object to them, before doing your normal world->screen calculations. It isn’t particularly efficient, but I don’t think anyone is going to be doing 1000 face polygons in Corona any-time soon so it shouldn’t be an issue.
I think the idea of manipulating the axes is simple enough, and the conversation is also simple.
If you have xAxis, yAxis and zAxis vectors (of unit length), then it is easy enough to see how a point (x, y, z) would be converted by doing:
[lua]local newPoint = vec.x * xAxis + vec.y * yAxis + vec.z * zAxis[/lua]
Of course, table addition doesn’t work like that but you hopefully get the idea, and I find most people tend to write their own vector libraries quickly enough to handle this sort of thing.
I’ll try all that. Thank you for the explanation! 
I find the dice demo shows a few things I tend to find a bit jarring. First you have the perspective up very high (although likely necessary in this case to show they are actually in 3D), and it is obvious that you are rotating using a set transform, as the actual manner of the rotation is very specific to using separate angles combined each frame in a specific order. I’d suggest using a pair of vectors (up and side) and rotating them (or I could suggest quaternions but frankly… no, just no. They are so damn complicated - imaginary number theory can bugger off!) to get a much more natural effect.
The lighting and shadow one is very nice, but I’m surprised you didn’t add in the bump-mapping composite filter (not having looked at it myself, I’m not sure if it would easily handle multiple light sources so if you tried and it wasn’t capable of it, forgive me). One detail that doesn’t show up clearly in the vid but I just made out, so you get big props for it, is the fact you are doing soft lighting on the shadow edges - a small detail that really makes a big difference. Really nice!
@rakoonic I went trough a lot of trouble making these demos because I didn’t have much background in working with any kind of 3D, projections nor anything to do with a little more intense math than usual. Although these are fairly easy concepts to digest I faced a few problems that required hackish solutions. I intend to put the source of both projects inside the code exchange section but first I want to find optimal implementations for these so others don’t get confused with my own code riddles.
As you pointed correctly the perspective was wrong. I have changed that but I’m not sure if I understand the vectors rotation you suggest and actually I’m very interested in this because when dealing with rotation I faced a few problems to make spinning look in one direction. My attempts to do this failed because the gimbal lock problem (or at least I think so). As for the quaternions I have spent lots of time (still do) trying to understand (miserably) fully the math behind it. I guess I’ll keep pushing there since it seems to be a MUST to step inside the 3D world.
The light’s and shadow’s demo is actually going to change a lot because I have found too much troubles with the current implementation. One of them is that internally the shadows are not being casted properly to the edges but rather to the vertices and the performance is very poor to use in production. This was actually one of the reasons of why I didn’t push further with the bump-mapping although I’m definitely going to try it.
Here is the source:
https://www.dropbox.com/s/fa75c9g69qg24my/DiceRoller.zip
https://www.dropbox.com/s/yske0pbp28z1q0x/Shadows.zip
I appreciate your keen comments.
Ivan.
Your perspective isn’t wrong, it is just exaggerated - it has the same effect as looking through a fish-eye lens, or in a first-person shooter game, upping the field of view a lot. Imagine if those dice were instead big buildings, the perspective would be fine for them, but since we know they are small objects, it just comes across as a bit odd. The solution in this case is to move the dice further away from the camera, and increase the screen scaling (IE scale up values *after* you’ve done the perspective divide). As a simple example, the following two bits of maths would produce a similarly sized object on screen, but the first one would have a ‘stronger’ perspective effect (due to it effectively having a wider field of view) - assumes the object you wish to draw is centered around the origin so that doubling the camDistance does actually double the overall distance between you and the object:
[lua]local camDistance = 5
local screenScalar = 10
local screenX = ( obj.x / ( obj.z + camDistance ) ) * screenScalar
local screenY = ( obj.y / ( obj.z + camDistance ) ) * screenScalar[/lua]
and
[lua]local camDistance = 10
local screenScalar = 20
local screenX = ( obj.x / ( obj.z + camDistance ) ) * screenScalar
local screenY = ( obj.y / ( obj.z + camDistance ) ) * screenScalar[/lua]
This isn’t working code of course, I am just trying to show the interaction of the ‘camera distance’ modifier, and the ‘screen scalar’ modifier and how they interact to allow you to tweak the strength of the perspective effect.
In the second sample the object is twice as far away as in the first sample, so the perspective calculation would leave it at half the size - hence why the screenScalar is twice the value to compensate.
I haven’t got time now, but I’ll look into your code later on if I can. Thanks for the trust!
[EDIT]I meant to add, that as a first dip into the water of 3D, you certainly did well. And yes, gimbal lock is the problem you were experiencing where 2 axes collapse into the same orientation preventing rotation in certain directions. Quaternions really aren’t necessary - where I’ve needed free-form 3D I tend to do what I briefly described above (maintaining and manipulating a pair of axes and basing everything off of that), because it is just a lot easier to understand.
What you do is define an ‘up’ and a ‘side’ (+x) pair of axes, and you manipulate them.
It is easy enough to rotate these vectors by an arbitrary axis, and you can easily maintain their stability by renormalising them and using cross-product maths to ensure they stay at 90 degrees to each other. Then when it is time to draw your actual model with these axes, you get the cross product for the third axes, and use these three axes as multipliers for each point to align the object to them, before doing your normal world->screen calculations. It isn’t particularly efficient, but I don’t think anyone is going to be doing 1000 face polygons in Corona any-time soon so it shouldn’t be an issue.
I think the idea of manipulating the axes is simple enough, and the conversation is also simple.
If you have xAxis, yAxis and zAxis vectors (of unit length), then it is easy enough to see how a point (x, y, z) would be converted by doing:
[lua]local newPoint = vec.x * xAxis + vec.y * yAxis + vec.z * zAxis[/lua]
Of course, table addition doesn’t work like that but you hopefully get the idea, and I find most people tend to write their own vector libraries quickly enough to handle this sort of thing.
I’ll try all that. Thank you for the explanation!
Just the samples I was looking for! Thank you soooooo much! You rock!
Just the samples I was looking for! Thank you soooooo much! You rock!
Hi,
i try run this sources, but corona simulator stopped working in both of them. Can you help me ? It’s there some setting what I must do before ?
Other projects work correctly.
Thank’s
I found problem,
simulator stopped working when it try to run this command:
display.newSnapshot
it’s some known problem ? How can I solved it ? On second PC everything work correctly. But I can’t to use this PC.
Hi,
i try run this sources, but corona simulator stopped working in both of them. Can you help me ? It’s there some setting what I must do before ?
Other projects work correctly.
Thank’s
I found problem,
simulator stopped working when it try to run this command:
display.newSnapshot
it’s some known problem ? How can I solved it ? On second PC everything work correctly. But I can’t to use this PC.