Stud logo toggle for Preview

[trevorsandy]

Is it reasonably possible to enable stud logos for preview, independent of view ?

lcLibrary takes into account the stud logo during inititalization but it will also reload primitives when instructed - e.g SetStudLogo(3, true). Additionally, it is possible to release and unload a part in the library so a subsequent call on that part should reload its associated primitives etc...

With this understanding, I created a PoC where I set the stud logo to 3 at the top of the SetCurrentPiece() call, release and unload the piece, load the piece (lcGetPiecesLibrary()->LoadPieceInfo(Info, false, true)), and at the end, reset stud logo to 0. Here is what the code looks like:

bool lcPreviewDockWidget::SetCurrentPiece(const QString& PartType, int ColorCode)
{
...
	bool StudLogo = mStudLogoAction->isChecked() && lcGetProfileInt(LC_PROFILE_STUD_LOGO) == 0;
	if (StudLogo)
	{
		mPreview->SetStudLogo(true);
		lcSetProfileInt(LC_PROFILE_STUD_LOGO, 3);
		lcGetPiecesLibrary()->SetStudLogo(3, false /*reload*/);
	}

	if (mPreview->SetCurrentPiece(PartType, ColorCode))
	{
...
	if (StudLogo)
	{
                mPreview->SetStudLogo(false);
		lcSetProfileInt(LC_PROFILE_STUD_LOGO, 0);
		lcGetPiecesLibrary()->SetStudLogo(0, false);
	}

	return false;
}

bool lcPreviewWidget::SetCurrentPiece(const QString& PartType, int ColorCode)
{
...
	if (Info)
	{
		if (mStudLogo)
		{
			Info->Release();
			Info->Unload();
		}
...
	return true;
}

The resulting behaviour is initially as expected but then the library parts become increasingly unstable. A common behaviour is when clicking on a part in the View, the part disappears.

Any ideas on what's missing ?

Cheers,

[leozide]

I think the parts are disappearing because you decrease the ref count with Release but don't increase it back after so eventually they get unloaded.

You can only have 1 mesh for a part so if you add stud logos to the preview you'll add it to the main view as well.

What use case is this? Sounds strange to have logos in only one place.

[trevorsandy]

Ah indeed, I overlooked resetting the ref count before loading the part.

What use case is this? Sounds strange to have logos in only one place.

The use case is to be able to visualise parts in preview as they appear physically while not taking on the performance hit and visual clutter of generating studs for the model displayed in the View - if one so chose. Of course, having to unload and reload prims and parts will decrease the advantage of not loading studs for the model displayed in View but I believe there will still be a net performance benefit.

Cheers,

[trevorsandy]

You can only have 1 mesh for a part so if you add stud logos to the preview you'll add it to the main view as well.

Indeed, hence the the set and reset calls in lcpreviewdockwidget::SetCurrentPiece. The thinking here is there will not be any View redraw calls during the SetCurrentPiece call.

Cheers,

[leozide]

Indeed, hence the the set and reset calls in lcpreviewdockwidget::SetCurrentPiece. The thinking here is there will not be any View redraw calls during the SetCurrentPiece call.

The mesh data is shared so the changes in the preview will affect the main view once it's redrawn.

[trevorsandy]

The mesh data is shared so the changes in the preview will affect the main view once it's redrawn.

Ok - then it is not possible to realise this use case.

Perhaps I did not see this behaviour in the main view as the ref count was not reset. In the PoC, logos were only present in the preview - even after manipulating the view model and preview part which I imagine should initiate redraw.

Cheers,