Lua Edu Tools beta version

[chris]

I don't know why I get this difference in size since this code is based on the one used in render.cpp
to calculate the size of a disc in pixel...
Please, would you have a clue about what's happening here ?

The size estimate used in render.cpp is deliberately conservative. I believe that what you really want to use is the distance to the center of the object, not the distance to the closest point on the bounding sphere. However, when the camera is close to an object, perspective will make it appear larger than the size of the square calculated based on the distance to the center.

--Chris

[Vincent]

The size estimate used in render.cpp is deliberately conservative. I believe that what you really want to use is the distance to the center of the object, not the distance to the closest point on the bounding sphere.

Actually, I did first use the distance to the center of the object. That's what I called my "empirical adjustment". However, the scale squares associated to 10^4 meters down to 10 meters were not displayed when approaching the Earth because there was still a large distance corresponding to the radius of the Earth. So I switched back to the distance to the surface of the object...

Anyway, Thanks for this clarification. I'll switch back to the distance to the center of the object as you suggested. I should easily find a fix to display the smallest scale squares.

[Jedi]

Vincent

First of all, I want to thank you for all the outstanding work that you have put into the tools. I have found them to be very easy to understand, adapt, and use.

To be able to draw the square on the object in the center, you need an angle that is tangent to the sphere. This makes a perfect square on the object.



To be able to draw the square at any FOV gives a problem. Since we are displaying a 3d universe on a flat screen, the acutual angles become obsure. This creates a warping effect on the picture that is displayed. For the default FOV and lower the effect is extremely minor and unseen. As the FOV becomes larger the effect becomes obvious.





The square is perfectly done on the object as the object is centered. If the object is moved away from the center then object becomes warped. This warping effect for the center square can be corrected by using a ratio of the tangent of half the default FOV and the tangent of half the current FOV.

By using your previous code for the square and the code used for determining the default FOV from your slider tool, I used the following code to create the pics above.

Code: Select all

drawScaleSquare = function(a)
   width, height = celestia:getscreendimension();
   centerX, centerY = width/2, height/2;
   gl.Color(0, 1, 0, 1);
   gl.Disable(gl.TEXTURE_2D);
   gl.Begin(gl.LINE_LOOP);
   gl.Vertex(centerX-a, centerY-a);
   gl.Vertex(centerX-a, centerY+a);
   gl.Vertex(centerX+a, centerY+a);
   gl.Vertex(centerX+a, centerY-a);
   gl.End();
end

local obs = celestia:getobserver();
local fov = obs:getfov();

local yRatio = 722/height;
local zoomToRad = 0.223832847;
local fovCoeff = 2/3*math.pi*zoomToRad ;
local defaultFov = fovCoeff/yRatio;
local fovRatio = math.tan(defaultFov/2)/math.tan(fov/2);

local sel = celestia:getselection();
local sel_rad = sel:radius();
local dist_to_sel = celutil.get_dist(obs, sel);
local sel_size_angle=math.asin(sel_rad/dist_to_sel);
local sel_size_pix= 2*height*fovRatio*math.tan(sel_size_angle);

drawScaleSquare(sel_size_pix);



As you can see the square is drawn on the surface of the object. If you want to square on the outside of the atmosphere, all you need to do is add the height of the atmosphere to the radius of the selection.

This will draw the square in the center of the screen. However, if you want to draw the square at a different location, the angles will need to be recalculated. While I didn't do these calculations in this code, it is still possible to create it accurately.

Once again, thank you for the tools in general.

[Jedi]

I made my last post before reading all of the posts in the last few days or even knowing what the squares were going to be used for. Now that I have looked at it, the scales is a add-on that is worth it. I noticed that the square's distance stays constant at all FOVs. That is good to see. I saw that the equation in the tool uses a modifier number of 1e3. That number is almost equal to the tangent of half of the default FOV divided by 4. That fits in closely with my rough numbers to make the squares almost exact (within 1 pixel). For a visual representation, that is excellent.

As always, thanks for the good work in the tools and in Celestia in general.

[Vincent]

Jedi,

First of all, thanks for diving into the Lua Tools' code ! Getting some help on the coding is really appreciated.

Then, I've tested your piece of code, and it actually works quite great. The only problem I have with it is that the size of the scale squares depends on the screen size/configuration. Can you confirm this issue on your system ?

[Vincent]

I did install Windows Vista in a third hdd this night and the strange thing is that the FOV slider actually works in Vista. But not perfect, the center of the slider isn't really centred. It's misplaced way to the left, but I can finally control the slider.

Anders,

I have good news for you !
I've managed to reproduce the fov slider bug on a system and thus, I've been able to find a fix. Could you please download the latest updated package and let me know if everything now works fine on your system ?

[tech2000]

I did install Windows Vista in a third hdd this night and the strange thing is that the FOV slider actually works in Vista. But not perfect, the center of the slider isn't really centred. It's misplaced way to the left, but I can finally control the slider.

Anders,

I have good news for you !
I've managed to reproduce the fov slider bug on a system and thus, I've been able to find a fix. Could you please download the latest updated package and let me know if everything now works fine on your system ?

Vincent: Confirmed, bug is killed. Great news..

[Jedi]

I was looking at the new scale option in the lua tools. As for me, I think that if the scale was in a circular path it would be less confusing to the eye and easier to read the scale.

Such as:



I also noticed that the scale was always centered. If the scale was centered on an object and it extended on the plane of the object, the scale would be more meaningful to all other objects in that plane.



The color of green may not be the best. That can easily be changed. Also the units I have for the pics is in AU, but can easily be changed to km, ly, parcs, or a combination of all of them.

If you want, I can post the code that produced these pics and you can examine it yourself for comparison.

[ElChristou]

...If you want, I can post the code that produced these pics and you can examine it yourself for comparison.

Please do so! any participation and discussion is welcome!

[Vincent]

I was looking at the new scale option in the lua tools. As for me, I think that if the scale was in a circular path it would be less confusing to the eye and easier to read the scale.

Since there seems to be some interest in both squares and circles, I think that adding an entry like scale_shape = "square" / "circle" in the config file would be a good compromise. Does it sound reasonable to you ?

I also noticed that the scale was always centered. If the scale was centered on an object and it extended on the plane of the object, the scale would be more meaningful to all other objects in that plane.

I also like the idea to have the scale square/circle drawn in the observer's vertical plane, as if the Tools were part of the camera display. This is really the philosophy I'd like to adopt for the Tools, and that I've applied so far, e.g., to the compass. However, displaying some tools in the background scene might be also interesting. So, what you suggested could be added as another option in the config file : scale_plane_mode = "true" / "false".

Then, since displaying the scale square/circle both in the equatorial plane of planets and in the ecliptic plane would be interesting, what would you suggest to switch from one plane to the other ?

Edit:What about adding the following entry in the config file ?
scale_body_mode = "observer" / "ecliptic" / "equatorial"

If you want, I can post the code that produced these pics and you can examine it yourself for comparison.

Yes, as Chris suggested, you can post it here or send it to <vince.gian@free.fr>. Thanks.


Finally, here's my answer to your previous posts. I think you missed it:

Jedi,

First of all, thanks for diving into the Lua Tools' code ! Getting some help on the coding is really appreciated.

Then, I've tested your piece of code, and it actually works quite great. The only problem I have with it is that the size of the scale squares depends on the screen size/configuration. Can you confirm this issue on your system ?

[Jedi]

Vincent

I emailed the Lua File for the Circular distance around a selection.

As you can see, the function does all of the work. It will draw a perfect circle around any object at a given distance in KM. The default is to draw it on the plane of the object. You can also input into the function values for the ascending node and inclination. That way you can draw it at any place around the object that you choose. On one test, I put two slider boxes to control the ascending node and inclination. It allowed me to move the distance circles around on the fly using those controls. That way the user could control where he would want the distance circles to be located.

Tell me what you think and/or release it with your zip file so others can see and test it as well.

[ElChristou]

Vincent

I emailed the Lua File for the Circular distance around a selection.

As you can see, the function does all of the work. It will draw a perfect circle around any object at a given distance in KM. The default is to draw it on the plane of the object. You can also input into the function values for the ascending node and inclination. That way you can draw it at any place around the object that you choose. On one test, I put two slider boxes to control the ascending node and inclination. It allowed me to move the distance circles around on the fly using those controls. That way the user could control where he would want the distance circles to be located.

Tell me what you think and/or release it with your zip file so others can see and test it as well.

Seems to be interesting! want to test!

[Jedi]

I think that the square distances are most meanful outside of a solar system while the circular distances on the plane is good for within the system. A good compromise to use the circular distances within a certain distance from the system and use the square distances outside of that. We could also use the circular distances within the system and the square distances always on. Another approach is to use the circular distances within the system and swith to the galactic plane outside of the system. There are many possibilites, all of which could be easily created. What do you think may be the best way to display this?

[hank]

I think that the square distances are most meanful outside of a solar system while the circular distances on the plane is good for within the system. A good compromise to use the circular distances within a certain distance from the system and use the square distances outside of that. We could also use the circular distances within the system and the square distances always on. Another approach is to use the circular distances within the system and swith to the galactic plane outside of the system. There are many possibilites, all of which could be easily created. What do you think may be the best way to display this?

If trial implementations are easily created, why not experiment with various alternatives to determine the best approach?

- Hank

[Vincent]

There are many possibilites, all of which could be easily created.
What do you think may be the best way to display this?

Jedi,

I've received your file, thanks. I'm really happy to see that the Lua Tools'
code is easily understood and customizable. Then, I particularly like your
idea to display the main successive distance markers (100 km, 1 AU,...
1ly, 2ly,...) instead of power of ten meters. I still have the same problem,
though: the size of the distance markers is dependant from the screen
size/resolution.

Then, I think that the best approach for now is to test every option, as Hank
suggested. That's why I've added the following entries in the config file:

Code: Select all

distance_marker_shape = "circle" / "square"
distance_marker_mode = "observer" / "equatorial"

Then, we will still be able to make the distance markers automatically
switch from circle to square and/or from the selection's equatorial plane
to the observer's plane if this appear to be the best solution.

I also think that the circle markers should be associated to the current
selection instead of a fixed object like Sol in the code you sent me.

Finally, I'm trying to add a semi-transparent sphere marker.
I think that this would be a really useful distance marker...

[Jedi]

Vincent

I've received your file, thanks. I'm really happy to see that the Lua Tools'
code is easily understood and customizable.

The ability to be so customizable makes it a very useful tool. It allows anyone the option of doing so many things without having to make a customized version of celestia from the source code.

If you noticed in the pics that I posted, the tools on the captured screen has a few added tools not discussed. I added a button to enable or disable the automag. There is also a check box for a tool that aligns the top of the screen to the north pole of the selected object. When I rotate around a planet, I always know that the top of the screen is north.

I have found that your tools as an extremely useful tool that extends many options.

I still have the same problem,
though: the size of the distance markers is dependant from the screen
size/resolution.

I am not exactly sure what you mean by this statement. Are you talking about how I use a ratio of the default FOV and the current FOV which changes from one system to another?

Working the math, I have concluded that this ratio accounts for the distortion in the higher FOVs. On my system, it seems to work perfectly. To make sure it works, I tested it in two ways. In both tests, I changed the Fov up and down to see how it appeared.

1.
I tested it by creating a SSC file for a plant at exactly a distance of 1 AU. This planet also had an inclination and eccentricity of 0. I then compared the 1 AU line with the planet's orbit at large and close distances to the line.

2.
In the "-- Init Circle Variables" section at the beginning of the file is the line "distanceType = "Circle"". If you change "Circle" to "Square" or anything else, instead of the circles, it produces squares centered in the center of the screen for the sun. In your scale Lua file, I changed the squares from the surface to the center of the object. If you goto the sun in celestia after you make these changes, then my squares should exactly match your squares.

On my screen, both of these tests worked as expected. Can you tell me how these tests works on your system? In that way we can know how the differences in screen sizes work on the scales that we put on the screen.

Your square distances uses a modifier of the (defaultFov / 4) for my screen. On your screen, the calculated defaultFov is not the same as on my system. For that reason, I would really like to know how the above tests works on your system.

[Vincent]

I am not exactly sure what you mean by this statement. Are you talking about how I use a ratio of the default FOV and the current FOV which changes from one system to another?

Jedi,

As an example, the more you increase/decrease the height of your
Celestia window, the more you increase the gap between the orbit of
Earth and the '1 AU' distance marker.

However, I've fixed this bug now. I've also optimized the code to add
a fading out effect to both the circle and the square distance markers,
and to display the circle markers until 10^9 ly.

I'll send you back an e-mail with the distanceBox.lua file so that you can
test it on your system.

[Jedi]

I am not exactly sure what you mean by this statement. Are you talking about how I use a ratio of the default FOV and the current FOV which changes from one system to another?

Jedi,

As an example, the more you increase/decrease the height of your
Celestia window, the more you increase the gap between the orbit of
Earth and the '1 AU' distance marker.

However, I've fixed this bug now. I've also optimized the code to add
a fading out effect to both the circle and the square distance markers,
and to display the circle markers until 10^9 ly.

I'll send you back an e-mail with the distanceBox.lua file so that you can
test it on your system.

Ooops.

I see the mistake and fixed myself. If you send me the email, I check that one as well.

[fsgregs]

Vincent:

I have finally loaded 150pre 3 and the Lua tools kit. It certainly gives the viewer a lot of instantly available tools to click on. I wish to thank you for all of this work. It will significantly add to the value of the educational activities (provided several quirks of 150pre3 are fixed).

I've checked the postings and did not yet find the following bug report. If it's been cited already, forgive me.

BUG:
When I load lua tools, it appears that there are no longer any "roll" controls in Celestia. The left and right arrows in Celestia are coded to create roll, and the 4 and 6 keys on the numeric keyboard create yaw. When Lua tools is loaded, however, the left and right arrows now create yaw, and the 4 and 6 keys are inactive. There are no "roll" keys.

We really need a roll capability to help orient us in space. Is there a keystroke somewhere I am missing? If not, could you add a roll capability?

Thanks

Frank

[Vincent]

BUG:
When I load lua tools, it appears that there are no longer any "roll" controls in Celestia. The left and right arrows in Celestia are coded to create roll, and the 4 and 6 keys on the numeric keyboard create yaw. When Lua tools is loaded, however, the left and right arrows now create yaw, and the 4 and 6 keys are inactive. There are no "roll" keys.

Frank,

I can't reproduce this bug on my system... All the keys are working as expected.
The Alt-Azimuthal Mode (CTRL+F) is automatically enabled in Planetarium Mode,
and then, the left/right arrow keys have the same commands than the 4/6 numpad keys.
But this is of course intended. Is this what you're talking about ?