Board index FlightGear Development Canvas

Livery Canvas resize ...

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Livery Canvas resize ...

Postby abassign » Tue Dec 11, 2018 10:07 am

I'm working with the canvas for liveries, but I have the impression that some problems with the memory of the GPU in the case of wanting to resize the size of the livery and then the canvas. From the tests I am making known that it seems difficult, if not impossible, to resize a canvas to decrease or increase the size of a livery (memory occupied in the GPU). It seems that the only way is to first perform the deletion of the canvas with the NASAL command "aCanvasObj.del (nil);" but I have almost the certainty in the fact that this command effectively deletes the canvas as an object in the system memory, but does not delete the equivalent copy in GPU ... this reducing the memory size available for the GPU and therefore the performance decrease to an intollerable slowdown of the system even with my 8 GB GPU. It would be necessary to be able to change the size of the canvas in the GPU, but a setSize or resize method does not seem to work on the canvas created at both the CPU and GPU levels and so I'm quite worried at the moment. If someone more about the topic I would be happy to understand how to proceed.

For example:

Code: Select all
ca = canvas.new({"name": "Fuselage",
                    "size": [ca_size,ca_size],
                    "view": [ca_size,ca_size],
                    "mipmapping": 1});
...
ca.addPlacement({"node": "A__G91_fuselage_int.weapon.door.001"});
...
   foreach(var image; [livery_001, dirty_001]) {
        print("G91: set_livery.nas image: ",image," (",size(image),")");
        # Insert the layer
        ca_root = ca.createGroup();
        if (size(image) > 0) {
            layers_001[image] = ca_root.createChild("image")
                .setFile(image)
                .setSize(ca_size,ca_size);
            if(image == dirty_001) {
                if (dirty > 0.1) {
                    print("G91: set_livery.nas dirty show: ",dirty_001);
                    layers_001[image].show();
                } else {
                    print("G91: set_livery.nas dirty hide: ",dirty_001);
                    layers_001[image].hide();
                }
            }
        }
    }


Once I've instantiated the livery ... I try to resize it, but I can not find a specific command to delete the canvas or resize it ...
I tried with this old canvas cancellation code:

Code: Select all
    if (ca != nil) {
        layers_001 = {};
        ca.del(nil);
    }


Actually I can create a new canvas with the new dimension I want, but in reality I do not delete the canvas in GPU which then becomes zombies and therefore slows down the performances. The only solution, which seems to be fueling, is to recharge the plane (!?), But I have doubts that it is a good solution.

I could think of creating a canvas of 4096x4096 (maximum size of our liveries) and then change the resolution with a view, but obviously it does not change because the "view" is only a command to define the geometry and has no impact on the memory actually occupied in GPU:

Code: Select all
    ca = canvas.new({"name": "Fuselage",
                    "size": [ca_size,ca_size],
                    "view": [4,4],
                    "mipmapping": 1});
....

ca_root = ca.createGroup();
        if (size(image) > 0) {
            layers_001[image] = ca_root.createChild("image")
                .setFile(image)
                .setSize(4,4);
....


I notice that when I do I delete the old canvas to rebuild the new one with a different size ... the GPU starts to increase the load considerably ... a clear indication that you have performed an incorrect operation (which is natural if the instanted canvas object does not manages, in this case, the method of () ...)

I hope that some of you know a solution to this problem.

This is an example of the slowdown of the GPU when changing the resolution of the canvas with the method of destruction and reconstruction of the canvas with a different size:

Start 4096
Image

change 2048

Image

change 1024

Image

etc ...

Image

Image

Image

Image

Image

The GPU is NVIDIA 1080 with 8 GB VRAM and the system is Intel I7-8700K @ 3.7 GHZ 25 GB RAM - SO: Ubuntu 18.10
FGFS version is 2018.4

Note: The effect of dark fuselage is at the end of the first resizing attempt, if you make another resizing with the same resolution, the correct image appears.
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

Re: Livery Canvas resize ...

Postby Hooray » Tue Dec 11, 2018 10:32 am

I am not sure if I understand the question or the motivation here, is this for feature scaling ?
Apart from that, I don't think that you can dynamically resize a Canvas texture at all, or how that would affect the previously used GPU memory.

Like you said, I would also do this sort of thing separately or by pre-allocating a sufficiently large texture first and getting rid of it afterwards. If this is about feature scaling, I'd probably use the view-based method you mentioned in conjunction with a sub-texture lookup (canvas image), which should refer to the same GPU memory.

Other than that, I don't think that you can resize the Canvas at runtime (I don't think I ever tried that though).
However, like I said, it may be better to share the problem you are seeing, rather then solution you want to see fixed.

Finally, if you think you need resize() capabilities, you could try the issue tracker and file a feature request there - but I'd suggest to be prepared to share the problem you are trying to solve.



EDIT:
This is an example of the slowdown of the GPU when changing the resolution of the canvas with the method of destruction and reconstruction of the canvas with a different size


In those screen shots showing the osg stats, what is it exactly that you'd like to point out to us here the bars or the curves ?
Are you familiar with the way the osg stats have to be interpreted ?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Livery Canvas resize ...

Postby abassign » Tue Dec 11, 2018 10:55 am

In fact I'm just trying to share the problem, and I think this is a suitable forum for discussion because I'm not a kernel developer.

However, I confirm that the canvas can not be destroyed or resized (at least for now) and the behavior of the GPU seems obvious to me.

I have however provided a parameter to initialize the resolution to be able to preset the size of the canvas at the beginning, but obviously, just for the characteristics of the canvas, I think it would be great to have a more dynamic canvas at GPU level, especially for complex aircraft like this (G91-R1B). Given the high generation speed of the canvs (even at 4096/8192) I would have liked to be able to vary its size according to the distance / position of the point of view.

I hope that some of the developers, now that has read the post, can take into consideration the problem, especially for the use of canvas with liveries, a type of use certainly not common, but in our case is giving me great satisfaction.
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

Re: Livery Canvas resize ...

Postby Hooray » Tue Dec 11, 2018 1:06 pm

so your goal is indeed about feature scaling, i.e. wanting to use different canvas textures/dimensions for LOD purposes ?
If so, I'd suggest to come up with more use-cases and benefits for the corresponding feature, and then file a feature request.

Apart from that, even if you were able to re-size the canvas dynamically, that would entail re-drawing it, too.
Thus, my original suggestion (using a texture map with different LOD resolutions) should still work reasonably well.
Keep in mind that under the hood, even PagedLOD will keep the corresponding textures around, and just toggle the equivalent of an osg::Switch on/off


If in doubt, raise this on the devel list or file a feature request - but to me, things sound still pretty confusing unfortunately.

For example, you talk about "GPU level", but seem to ignore that there must be a step to actually upload the corresponding texture to the GPU - so, if you'd like to use different resolutions, another potential idea might be to expose native osg LOD support to the Canvas, so that it uses a lower resolution for certain textures based on the distance/viewpoint of the placement (a canvas as such has no actual location other than residing in the GPU's VRAM)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Livery Canvas resize ...

Postby Thorsten » Tue Dec 11, 2018 2:40 pm

I think it would be great to have a more dynamic canvas at GPU level, especially for complex aircraft like this (G91-R1B). Given the high generation speed of the canvs (even at 4096/8192) I would have liked to be able to vary its size according to the distance / position of the point of view.


This sounds like what is otherwise known as 'mipmapping' - which you can set to 'true' when you initialize your canvas (in fact I think it defaults to true) and LOD is then handled by the GPU.

We otherwise don't assign different sized non-canvas textures to surfaces beased on distance and position either - it's a bad idea because the texture loading process is expensive, which is why people came up with mipmapping in the first place I guess.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Livery Canvas resize ...

Postby Hooray » Thu Dec 13, 2018 9:31 pm

I cannot currently find the postings, but I do remember TheTom mentioning plans on adding support for dynamically resizing canvas textures "on the fly" - but probably for other purposes.

@OP: If in doubt, look up the wikipedia article for mipmapping on your native language to see if it fits your needs or not, and then report back here.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU


Return to Canvas

Who is online

Users browsing this forum: No registered users and 5 guests