Perspective large and complex SVG animation tips please

Hi all,
I’m creating some overview views for an entire factory, containing many conveyors and machines.
I need to change the colour and visibility of individual items to show status.

I have a very simplified 2D layout drawing in AutoCAD, which I can import into Inkscape and convert to SVG, then import into a Perspective view.

This is relatively easy for small SVGs, but I’d like ask for any tips please, on how to do this at a large scale with many items. The risk being that, if there is one thing that is certain, it is change. When the layout changes, I don’t want to do all of the bindings again.

My current theory is to simplify each SVG down to small manageable chunks and use the same X,Y datum and image size for every SVG, then overlay with the X and Y position for all at 0, so everything will end up in the right place and scale as per the original drawing. Each machine effectively becomes a layer.

If some part of the layout changes, I can delete those “layers” and import the new SVG(s), and I only need to re-do a small number of bindings.

I’ve seen something similar with images from over-complicated CAD drawings with SVG overlays. The result was terrible as it was very slow to re-draw.

Am I on the right track, or do I have a complete misunderstanding?
What is best practice in this scenario, and how do I get the best performance, while future proofing flexibility?

Thanks.

@nader.chinichian tagging you in.

Importing every thing form autocad is wrong. you need to draw it to make result optimize. And yes it is hard.

Then divide the object in layout and put them on embedded view as overlay on diagram.
Change all property of svg by python script don’t use binding.

2 Likes

Is this for performance or convenience? Or something else?

2 Likes

This mostly for convenience as we always change model in Inkscape and import it again and again.
And some times you have a lot of same type objects like pipelines and you want all pipeline color be dynamic base on your tags, doing binding for 6000 pipelines is extremely boring, so you can write some basic python code and trigger it base on some specific event to dynamic color for each pipe elements.

you can create your own protocol and rules in drawing and make object proper id so in perspective you can map them easily.

you can also create your own parser by using perspective upload component and try to read xml file(SVG) and create custom SVG structure as perspective SVG format with binding.( you can always can modify views )

1 Like

Oh no, and if you’re not a super human python guru like you?! :grimacing:

Believe me, I’m NOT even a good programmer and before knowing ignition I don’t Python at all.
For some project, client invest a lot of money, so doing the workflow I describe worth your time and effort.
You can hire someone to do that part for you and create your lib and think it as investment.
Even this is true in any other SCADA packages.
The only thing is different is power SCADA packages that support AUTOCAD reading and create matrix base on the graph and make it dynamic.
The good thing about ignition it is also possible here but you need to do it. Compare it to WinCC, Citect, Indusoft, … which you can’t do this even you know how to do that.

1 Like

Thanks for the tips Nadar, much appreciated.

If you know something about svgs/html
You could also import the svg “string” right it into the iframe.

This should basicly work with almost anything inkscape can pushout, no need to convert it into something igntion knows.

	data = "data:image/svg+xml,"	
	svg= "<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 96 96'><rect  width='100%' height='100%' stroke='"+value+"'/></svg>"
	return data + svg

is this easier or good practice, idk just giving you another option xd
most editors put in classes or svg animation with ids on the top, that should be not to hard to edit…

1 Like

@victordcq what would you do if you needed to interact with the graphic, like a button press? How would iFrame handle that?

Currently its not possible to interact with seperate parts of an svg in perspective, unless you use javascript.

Be it through a module or by injecting an api call in the iframe that points to webdevmodule on the gateway.
(So its not easy xd)

An svg that isn’t embedded.

Embedding large and complex svg’s though does become a performance issue though.

even embedded svgs cant determine which part of the svg is clicked? or did they finish the feature for it?

I didn’t read that as clicking on an element of the svg, but rather on a button external to the svg, and then reacting to that click by changing the svg.

Ah i see

@jlandwerlen if that is what you asked than i already did a showcase with a binding xd
just change the props.src on button click works too

It was more to update this post so the OP was aware of the limitations and if any differences with iFrame. It may not be well known.

Ahh i see.
Yes, if it was possible to know which svg element was clicked. Than it definitly would have to be with using the embeded svg.
But htats not possible yet.

With the iframe i might be possible to put onclick’s on the svg and let them call an something from the webDev…
I’ve not tested that, because it would be super cluncky to use and i already have a perspective module for svgs.

That was an interesting conversation. I have to admit, I had never considered any of those options.
If I wasn’t so worried about click events, and was more interested in changing the colour or visibility of elements within the SVG dynamically, based on the status of each machine, would that change your recommendations?

I’m still trying to get my head around Nadar’s scripting suggestion.

I was half expecting (read: hoping!) @pturmel would have some clever module that he’d written in a few lines of code?!

1 Like

So @victordcq has written a module to handle click events for SVG.

I think the first idea @nader.chinichian had was to use scripting over bindings. If you use bindings and update the SVG, then you will most likely wipe out and break the bindings. Scripting wouldn’t have this limitation, plus using scripting potentially you could have all scripts in one location, depends on how you have things arranged and your needs.

I am however a little confused on what he meant by creating own protocol and using rules in the drawing. Maybe @nader.chinichian you could clarify and perhaps even give an example?

I mean grouping similar objects so in script toy can access them very easily.
Also put some special char like .@# string in object Id so again when parsing this Id in perspective you know more about which elements you are in.