New ScriptImage/InfoImage/InfoText functions - DOWNLOAD !!

[Vincent]

Hi,

Here's the final release of the overlay image/text functions. This version allow the user to display :
- any overlay image during a script => ScriptImage function
- any overlay image during navigation => InfoImage Function
- any overlay text during navigation => InfoText Function

> You can find information about how to use the ScriptImage function here :
http://celestiaproject.net/forum/viewtopic.php?t=9123&start=87
> To display InfoImage and InfoText on screen, you only have to press the [V] key several times to choose the 'Ultra Verbose' mode, or to check the 'Ultra verbose' button in the "Render > View options" Menu.

Based on the same use as the InfoURL function, any object can have specific InfoImage and InfoText that will be displayed when the object is selected and the 'Ultra Verbose' mode activated.

For example, if you want to add InfoText and InfoImage for Saturn's moon Titan, just add these lines in the .ssc definition of Titan in solarsys.ssc :

Code: Select all

InfoImage "infoimage_Titan.jpg"
InfoText "
Discovered by Christiaan Huygens
Date of discovery 1655
Mass (kg) 1.35e+23
Mass (Earth = 1) 2.2590e-02
...
"

Or just add this .ssc file in your extras folder :

Code: Select all

Modify "Titan" "Sol/Saturn"
{
InfoImage "infoimage_Titan.jpg"
InfoText "
Discovered by Christiaan Huygens
Date of discovery 1655
Mass (kg) 1.35e+23
Mass (Earth = 1) 2.2590e-02
...
"
}

Image files (like infoimage_Titan.jpg) must be placed in the 'images/infoimages' subfolder. Their dimensions must be power of 2 : 128, 256, 512, 1024. The 3 standard formats for Celestia are accepted : jpg, png and dds.

- The InfoText and InfoImage functions can be applied to every Celestia-object :
- Bodies (planets, moons, asteroids, comets and spacecrafts)
- Locations
- Stars (and barycenters)
- Deepsky Objects (galaxies, nebulae, open clusters)

- InfoText examples are available for Mercury, Venus, the Earth, the Moon, Mars, Titan, Apollo 11 landing site, the Sun and the Milky Way.
- InfoImage examples are available for Mars, Titan, Apollo 11 landing site, the Sun and the Milky Way.

Here are some screenshots for Titan / Apollo 11 landing site / the Sun / the Milky Way :



----------------------------------------------------------------------------------
Here are the links to download the needed files :
- Windows (.exe): http://vincent.gian.club.fr/celestia/ce ... patch3.zip
> As usual, just unzip and paste the content of the celestia_win32_1.4.1_patch3 folder into your main Celestia folder. No file will be overwritten.

- Modified source files for compilation (gtk and kde files included) : http://vincent.gian.club.fr/celestia/ce ... patch3.zip
> If you want to check the changes, just make a search for 'Vincent'.
----------------------------------------------------------------------------------

[ElChristou]

Excellent Vincent!! Sounds like a very cool new feature; once more as soon as Dirkpitt is completly settled, we will test on osX.

Many Tx for the effort.

[Sui Ota]

It's a great feature! Thank you, Vincent!

I found a bug:

There is something wrong about Information Text radio buttons of View Options window.
For example, in 'Verbose + Image' mode, no entries of the radio buttons are checked. You can easily verify it by toggling the information with V key, with keeping View Options window open.

[Chuft-Captain]

Excellent work Vincent!

I didn't activated this function for stars, deepsky objects and location yet. But that will be done after the test phase is over.

Don't forget spacecraft and other objects, or is your plan to make it available to any object regardless of object class (like InfoURL)?

BTW:
I did a bit of playing around (using your previous test release ) with a transparent PNG image, and it doesn't display the PNG at all. The image however displays perfectly fine on a webpage.

[Vincent]

Once again, thanks a lot for your support and feedback !

I found a bug:
There is something wrong about Information Text radio buttons of View Options window.

Yes, you're right, and I was aware of that bug. I've been trying to work this out for hours, with no result. It has something to do with the value of the radio button in the resource.h file. Anyway, I decided to release the test version since this is only a 'visual' bug that doesn't affect the use of the function. I'll have a better look at it later.

Don't forget spacecraft and other objects, or is your plan to make it available to any object regardless of object class (like InfoURL)?

Yes, I will extend the overlay function to stars, deepsky objects and locations as soon as the test phase is over, since that needs a bit more coding (that I know how to do).
Concerning spacecrafts, they're defined as 'Bodies' in Celestia's code, so you can already use the overlay function with them.

I did a bit of playing around (using your previous test release ) with a transparent PNG image, and it doesn't display the PNG at all. The image however displays perfectly fine on a webpage.

That works perfectly on my system. Please, make sure the dimensions of your image are 128, 256, 512, 1024...

Excellent Vincent!! Sounds like a very cool new feature; once more as soon as Dirkpitt is completly settled, we will test on osX.

Thanks Chris ! I really appreciate your support . I'm really waiting for you to tell me how the compilation goes under Mac OS...
I also noticed you started a discussion about my work on the devs' mail. As for that, I think the point is not whether we need to add another information aid or not. The information images were only made as examples. Overlay images can be used in a more general way for addons, to include photos, graphs, etc...

[Chuft-Captain]

I did a bit of playing around (using your previous test release ) with a transparent PNG image, and it doesn't display the PNG at all. The image however displays perfectly fine on a webpage.

That works perfectly on my system. Please, make sure the dimensions of your image are multiples of 2 : 128, 256, 512, 1024.

Yes, you're absolutely right. I realised after I posted this that the image was 512x351 (I'd forgotten about the ^2 requirement)
Do you have any plans in the future to relax this requirement, or is there a technical reason that there is this limitation?

BTW: a couple questions; I wonder if you've already thought about:

1. If running Celestia in a minimised screen rather than full screen, then the test images display partly off the screen, whereas the scene itself scales to the screen size. (obviously because the images are fixed size and you've used absolute rather than relative positioning, there's prob. no easy solution). My suggestion would be to express the XYoffset positions in terms of a percentage offset of the screen-size and have your code calculate the absolute offset. Of course this is not going to solve it completely unless you also scaled the images, and most people will prob. be running full-screen anyway, so I don't think it's a big deal.

2. I assume it's possible to set and unset the +images verbosity level within a script? Someone could have images defined in the SSC for some objects, so that they automatically display when the script selects the object (assuming verbosity +image is set). They may have custom images for other objects (displayed by the script) and they may also want to occasionally override the default SSC images in the script. ie. First visit to an object may display the default image, whereas on visiting the object a second time, they may want to display a different image. If the +images is on, then both SSC and SCRIPT images will display and may overlap..

3. Is it possible to specify the screen position of the SSC defined images? They seem to always display on RHS of the screen.

Thanks Vincent, good stuff!
Hope my comments help.

[Malenfant]

I think this is a great idea, but I wonder if there's a way to use this sort of thing to actually display a text info window instead of an image containing text. (the text could be stored in a normal txt file that Celestia reads).

[Joe]

Hi, Vincent

I think the bug relating to the radio button is caused by the value of IDC_INFOIMAGE in the resource.h file. To fix it, IDC_INFOIMAGE should be a consecutive number to the value of IDC_INFOTEXT2, i.e,
#define IDC_INFOIMAGE IDC_INFOTEXT2 + 1

[Vincent]

Hi, Vincent
I think the bug relating to the radio button is caused by the value of IDC_INFOIMAGE in the resource.h file. To fix it, IDC_INFOIMAGE should be a consecutive number to the value of IDC_INFOTEXT2, i.e,
#define IDC_INFOIMAGE IDC_INFOTEXT2 + 1

Hi Joe,
Yes, you're right, I've already tried that. The problem is that the "IDC_INFOTEXT2 + 1" value was already affected to IDC_BOOKMARK_CREATEIN. So, I tried to increment by 1 all the next values but curiously that didn't work... And the "Add Bookmark" pop up window didn't work anymore... I'll have a better look at it, but if you find any solution, please post it here... Thanks !

[Vincent]

1. If running Celestia in a minimised screen rather than full screen, then the test images display partly off the screen, whereas the scene itself scales to the screen size. (obviously because the images are fixed size and you've used absolute rather than relative positioning, there's prob. no easy solution).

Chuft-Captain,
That's an interesting point. With due consideration, I deliberately chose to set the position of the image relative to the center of the screen because that's the only way to keep the image fixed to the background scene. For example, if an image of an arrow is used to point out a specific place on the Earth, it has to point out the same place whatever the screen dimensions are.
The image's left side position is defined as: left = (width - xSize)/2 + imageXoffset
where 'width' is the Celestia window width, and 'xSize' the horizontal size of the image. If 'imageXoffset' was defined as a relative value, the image wouldn't stay at a fixed place relative to the Celestia objects in the background scene.
Then, as for the size of the image, we would have the same problem if it was relative to the size of the screen, since the Celestia objects are not resized when the user resizes the screen.

As for your second point, the current code I wrote uses 2 different functions to display images from scripts and from .ssc files. To increase the performances, I've been trying to change my code in order to use one single overlay function. If I manage to do that, I'll have to define a priority order to display the images...

3. Is it possible to specify the screen position of the SSC defined images? They seem to always display on RHS of the screen.

I already thought about that, but IMHO, since this is already possible with scripts, the .ssc definition should remain as simple as possible... We need other users' opinion here...

Thanks for this very constructive feedback !

[Vincent]

I think this is a great idea, but I wonder if there's a way to use this sort of thing to actually display a text info window instead of an image containing text. (the text could be stored in a normal txt file that Celestia reads).

Malenfant,
I also had a thought about that. But I didn't build the image overlay function specifically to add another information aid... This is only an example of how to use it. Then, if we agree on the necessity of adding more information, I think it would be indeed very useful to combine the image overlay with a text window...

[Joe]

Hi Joe,
Yes, you're right, I've already tried that. The problem is that the "IDC_INFOTEXT2 + 1" value was already affected to IDC_BOOKMARK_CREATEIN. So, I tried to increment by 1 all the next values but curiously that didn't work... And the "Add Bookmark" pop up window didn't work anymore... I'll have a better look at it, but if you find any solution, please post it here... Thanks !

Hi, Vincent,
I realised that you want to keep the original code intact as much as you could, but I think you have to re-define the those values from IDC_INFOTEXT0 to IDC_INFOTEXT2 and IDC_INFOIMAGE, avoiding changing the other IDs like IDC_BOOKMARK_CREATEIN onwards. I tried following and it works:

#define IDC_INFOTEXT0 10000
#define IDC_INFOTEXT1 10001
#define IDC_INFOTEXT2 10002
#define IDC_INFOIMAGE 10003

[Chuft-Captain]

1. If running Celestia in a minimised screen rather than full screen, then the test images display partly off the screen, whereas the scene itself scales to the screen size. (obviously because the images are fixed size and you've used absolute rather than relative positioning, there's prob. no easy solution).

Chuft-Captain,
That's an interesting point. With due consideration, I deliberately chose to set the position of the image relative to the center of the screen because that's the only way to keep the image fixed to the background scene. For example, if an image of an arrow is used to point out a specific place on the Earth, it has to point out the same place whatever the screen dimensions are.
The image's left side position is defined as: left = (width - xSize)/2 + imageXoffset
where 'width' is the Celestia window width, and 'xSize' the horizontal size of the image. If 'imageXoffset' was defined as a relative value, the image wouldn't stay at a fixed place relative to the Celestia objects in the background scene.
Then, as for the size of the image, we would have the same problem if it was relative to the size of the screen, since the Celestia objects are not resized when the user resizes the screen.

I think it's absolutely the right decision to have the [0,0] point in the middle of the screen. When I said relative, I meant relative to the screen dimensions, so all else being equal (FOV, distance, etc) then the top-left corner of overlays would always display in the same position relative to objects in the scene, regardless of the end-user's screen resolution, (although of course they'd appear 1/2 the size on a 1600x1200 screen than on an 800x600 screen).

Actually from what I've seen in Celestia, when you mimimise/maximise the screen, Celestia appears to change the FOV value appropriately so that it doesn't have to re-size the objects, but I think it's reasonable to assume that the screen-size is not going to change during the execution of a script.

With regard to relative positioning, it seems Celestia users may have screen resolutions anything from 800x600 up to 1600x1200, so IMHO it's an important design criteria to allow scripts to be written independent of target users screen resolution (however I'm not the one writing the code )
Perhaps however there is an alternative: If there is a function in CEL or CELX to return the current screen dimensions -- then any script-writer who wants to have resolution independent overlays in scripts could do the maths to transform from relative to absolute values in their script, and pass the results as arguments to your commands.
I'm no expert on cel-scripting so I'm not sure if those functions exist. (I'm also assuming that your commands will accept variables as parameters, as well as literals.)

As for your second point, the current code I wrote uses 2 different functions to display images from scripts and from .ssc files. To increase the performances, I've been trying to change my code in order to use one single overlay function. If I manage to do that, I'll have to define a priority order to display the images...

I can't remember what my second point was, but I think it was to do with the issue of whether to allow SSC overlays display at the same time as scripted overlays. I also thought about the idea of prioritising them, but IMHO the approach offering the most flexibility would be to allow 1 or the other, or both, to be displayed at the same time (as you have it now). It would be up to the script writer to position the scripted overlay in an appropriate screen position so that it didn't interfere with the SSC version. In fact some useful additional effects may be possible by deliberately overlapping certain transparent scripted overlays with the SSC generated ones.
I think however that this approach would require an extra script function to be provided by you so that the user could selectively enable/disable the display of the SSC overlay (+image) from the script. ie. A "Change verbosity" function in the script.

3. Is it possible to specify the screen position of the SSC defined images? They seem to always display on RHS of the screen.

I already thought about that, but IMHO, since this is already possible with scripts, the .ssc definition should remain as simple as possible... We need other users' opinion here...

Fair enough. and yes I think the opinions of those who've written a lot of scripts in the past would be constructive.

Whew! It's taken what seems like an hour to phrase this in a way which I hope will make sense, so I hope it does make sense (or at least gives food for thought).

[Vincent]

With regard to relative positioning, it seems Celestia users may have screen resolutions anything from 800x600 up to 1600x1200, so IMHO it's an important design criteria to allow scripts to be written independent of target users screen resolution (however I'm not the one writing the code )

Chuft-Captain,
When you change your screen resolution, the number of pixels changes, and so does the size of each pixel. Then, the overlay image is resized/moved in the same proportion as the objects in the background scene. That's why the image of an arrow will point out exactly the same place in the background scene whatever screen resolution you are using... The current code definitely allow the overlay script command to be independent from the users screen resolution. If you're not convinced, just run the overlay_test.cel script and try to switch between different screen resolutions...

[Chuft-Captain]

Vincent,

Perhap's I misunderstand you or visa-versa, so here's some snapshots of demo script in 1024x768 and 800x600 resolutions.
NOTE: FOV is approx. the same (20deg) in each case.

Hope this helps.

1024:


800:

[Vincent]

Chuft-Captain,
Ok, I understand now what you were talking about. Six huge screenshots are very much more explicit than words, even if you took an hour to write them...

Let's sum up what we have both pointed out.
- The size of the objects displayed in the background scene depends on the FOV whereas the size of the Image Overlay is independant to the FOV.
- If the FOV is not set in the script, and if the user keeps the default value, there is no problem using different screen resolutions since Celestia changes the FOV to resize the objects that are displayed on screen. (that was my point).
- If the FOV value is set in the script, or if the users set manually the FOV to a different value than the one used by the script writter, the size of the image overlay won't remain proportionnal to the size of the objects in the background scene. And there will be a problem (that was your point).

I'll have a look at the code and try to work this out...

Thanks !

PS : Can you please resize your screenshots to allow a more convenient reading ?

[Chuft-Captain]

Chuft-Captain,
Ok, I understand now what you were talking about. Six huge screenshots are very much more explicit than words, even if you took an hour to write them...

A picture's worth a thousand words.

Let's sum up what we have both pointed out.
- The size of the objects displayed in the background scene depends on the FOV whereas the size of the Image Overlay is independant to the FOV.

Yup

- If the FOV is not set in the script, and if the user keeps the default value, there is no problem using different screen resolutions since Celestia changes the FOV to resize the objects that are displayed on screen. (that was my point).

I'm not entirely sure what you mean. Maybe a picture or two would explain?

- If the FOV value is set in the script, or if the users set manually the FOV to a different value than the one used by the script writer, the size of the image overlay won't remain proportionnal to the size of the objects in the background scene. And there will be a problem (that was your point).

I wouldn't worry too much about scaling the images if I were you - that could create worse problems (jpg artifacts etc). The main thing is to get the positioning right.
I think as long as there was a way (either in your code or in cel/celX scripts to calculate absolute offset depending on the resolution, that would be OK. That would mean the center-point of the image would always be in the same place (even if the overlay size varied from one resolution to the next) - I suggest you look up the scripting documentation and see if there's a function(s) that returns the users screen resolution, then as I mentioned earlier, you could leave it up to individual script writers to do their own math (as long as their results can be passed to your overlay {} function.) Sorry I'd look it up for you but a bit busy right now.

PS : Can you please resize your screenshots to allow a more convenient reading ?

Your wish is my command line.

[Chuft-Captain]

Vincent,

Because a picture's worth a thousand words, here's how I (as a script writer) would think of the "virtual screen" on which to place overlay images.



Assuming your code could interrogate the user's screen resolution, then the position on screen (centre of the image) could be specified as a -ve or +ve fraction of 1.0 (or maybe as a percentage of 100) from the centre of the screen.
With this scheme the equivalent of your test script might read something like:

Code: Select all

{
overlay { duration 5 filename "image.jpg" }
wait { duration 5 }
overlay { duration 5 alpha 0.5 filename "image.jpg" }
wait { duration 3 }
overlay { xoffset -0.75 yoffset -0.75 alpha 0.5 filename "image.jpg" }
wait { duration 3 }
overlay { xoffset -0.75 yoffset 0.75 alpha 0.5 filename "image.jpg" }     
wait { duration 3 }
overlay { xoffset 0.75 yoffset 0.75 alpha 0.5 filename "image.jpg" }     
wait { duration 3 }
overlay { xoffset 0.75 yoffset -0.75 alpha 0.5 filename "image.jpg" }   
wait { duration 3 }
}

Your overlay code would internally mutiply the inputs by 1/2 the horizontal or vertical resolution. (and possibly adjust for image width/height)

eg. 1024x744 screen:
INT(-0.75 * 1024/2 ) = -384; INT(-0.75 * 744/2 ) = -279

eg. 800x576 screen:
INT(-0.75 * 800/2 ) = -300; INT(-0.75 * 576/2 ) = -216

etc....

Of course this all hinges on whether your code can get the current Celestia window size, but it's C++ so that shouldn't be a problem.

Just an idea, but what do others think?

Bye

[Vincent]

I wouldn't worry too much about scaling the images if I were you - that could create worse problems (jpg artifacts etc). The main thing is to get the positioning right.

I agree with you, but a lot of users will use the image overlay as an overlay texture that will have to suit very precisely the background scene... The non-scaling option would be a problem for them...

I suggest you look up the scripting documentation and see if there's a function(s) that returns the users screen resolution

The "celestia:getscreendimension()" lua function returns width and height of Celestia-window. (I have quite a good experience at writting cel and celx script... ) But since this function is only available in celx, all this has to be done in the source code. Before releasing the image overlay test version, I hesitated between using the current xoffsett definition and the relative one you suggested. Asking for a relative fraction of screen dimensions with values from -1 to 1 can be a good option.

Of course this all hinges on whether your code can get the current Celestia window size, but it's C++ so that shouldn't be a problem.

That is not a problem indeed, since the current overlay function already uses the width and height of celestia-window.

I'll provide a new test release as soon as possible.
Thanks a lot Chuft-Captain, your help is really appreciated.

[Vincent]

Ok, here are the new relative coordinates of the center of the overlay image that are defined in the code :

int imageCenterX = width/2 + (width*imageXoffset)/2
int imageCenterY = height/2 + (height*imageYoffset)/2

or in a nicer way :

int ImageCenterX = width*(1 + imageXoffset)/2
int ImageCenterY = height*(1 + imageYoffset)/2

- width and height are the dimensions of Celestia-window
- imageXoffset and imageYoffset are set in the script and can take values from -1 to 1 relatively to the center of Celestia-window.

But I really want to improve this to integrate the option that the user manually resizes the window...