Hi JP,

> for instance, when changing material options, the 3D board is not redrawn, 
> giving the impression of an unresponsive command

You mean when changing options in the Preferences?
It is true that some commands are not updating / reload the view,
I didn't made yet a proper logic behavior on that because some of the reasons 
explained below related with reloading.

> 1 - your rev 6066 (Do not redraw the 3D viewer after a change in pcbnew) is 
> not good.

> I saw the comment:
>     // This function is used by moduleframe.cpp
>     // while editing the pcb board, so it will not redraw to not slow the 
> pcbnew
> But if the user displays the 3D view during an edition, he expects to see the 
> changes
> (on my computer, a change in footprint editor takes less than 0.1 sec to be 
> redrawn in the 3D viewer)

As you see in the comment, it was firstly implemented that way: Any change on 
pcbnew it will reload the 3D-Viewer and redraw.
But after some user feedback (Maurice) and I try it my self, on complex boards 
(eg: with fill zones) it will take longer
(eg: the video demo, depending on the 3D options, can take 2 .. 10 seconds)

During that time, the 3D-viewer will use as much as possible the CPU to reload 
the board and it is not practical to make changes during that time on pcbnew.
Everytime you change a footprint or track.. etc.
How does the stable 3d-viewer behaves?
I understood that it was not updating until you click on the windows. I was 
trying to follow the same behavior.


This is all related with some of my initial idea just before start working on 
this new 3D viewer, I was expecting that the changes on pcbnew could be fast 
updated on 3D-viewer - almost realtime.
At this moment, I didn't implemented it yet because I was looking for changes 
on pcbnew that will be needed.
For instance, the pcbnew is just flagging that the 3D viewer needs to be 
reload, but I was looking for a way that it could tell with more precision what 
changed.
So it will be possible to tell if it was a footprint change, what layers were 
effected, if the fill zones changed, etc..

that way, it would be possible to just change that specific part and quickly 
update the 3d-viewer.

That is way I didn't yet implement properly the updates while changing 
parameters (Preferences) because I was looking for some general way to flag 
with precision the 3d-viewer on what changed.

Any suggestions?
Would it be possible to do on pcbnew?


> 2 - A minor other issue:
> if you rotate the view from the toolbar icons, there is a strange mix of 
> raytracing and opengl
> mode, until you change the view from the mouse.

Yeah there are still some strange states, I will have a look...

> Thanks, Mário, for your hard work.

Thanks for your valuable testing!
Mario


________________________________________
From: jp charras [jp.char...@wanadoo.fr]
Sent: 22 June 2016 07:33
To: Mário Luzeiro; kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation

Le 21/06/2016 à 19:07, Mário Luzeiro a écrit :
>> I think there are other tweaks to be made but they can wait. :)
>

About tweaks, I found 2 minor issues:

1 - your rev 6066 (Do not redraw the 3D viewer after a change in pcbnew) is not 
good.
 It has side effects: for instance, when changing material options, the 3D 
board is not redrawn,
giving the impression of an unresponsive command.
I saw the comment:
    // This function is used by moduleframe.cpp
    // while editing the pcb board, so it will not redraw to not slow the pcbnew
But if the user displays the 3D view during an edition, he expects to see the 
changes
(on my computer, a change in footprint editor takes less than 0.1 sec to be 
redrawn in the 3D viewer)

2 - A minor other issue:
 in Opengl render, if you click on the thirst icon of the toolbar, you run the 
raytracing only once.
 This is true if you change the zoo, orientation ... from the mouse.
 But if you rotate the view from the toolbar icons, there is a strange mix of 
raytracing and opengl
mode, until you change the view from the mouse.


Thanks, Mário, for your hard work.

--
Jean-Pierre CHARRAS

_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Reply via email to