[BETA] Shapediver Export Download Component - download not updated

Hi all,

I’ve uploaded ‘‘20211224 Moondoor grid maker’’ to my account ‘‘moondoor’’ / ‘‘info@moondoor.nl’’

The configuration updates in the GH model. But when I upload it to Shapediver, the Shapediver Export Download Component stops working after 1 succesful attempt.
Please visit: Test environment to see how it doesnt update.

Any ideas about the cause and/or solution?

Best, also for the holidays,
Thomas

Did you compare results with exports directly on the new platform? And on the legacy (old) platform? Is the same issue happening in all environments?

Hi Mathieu,

I just tried it, it happens in both the new and the legacy platform. :frowning:
However, the downloader seems to work fine when I try to output a .3dm file. So I guess it has to do with the compliation of my .IFC file. I will ask GeometryGym for help.

Best, Thomas

Hi Mathieu / SD,

I asked Jon Mirtschin from GG for help: IFC unreadable - #4 by moondoor
His answer seems to point to an issue in your engine not delivering the updated output of this ggIFc stream component? IFC unreadable - #6 by jonm

Can you help?

Best, Thomas

Hi Thomas, Did you confirm the streaming works fine when you use the gh script locally on your own computer?

Hi Jon,

Good idea, I actually did not. But now that I did, I can confirm the streaming works fine locally.
I copied the data from the stream for two different configurations and they came out as expected:
Test locally 2.txt (15.8 KB)
Test locally.txt (12.1 KB)

Im not allowed to upload IFC but here they are in .txt Changing the format to .ifc allowed me to load them into an IFC viewer (Solibri anywhere) just fine.

Best and thanks so far,

Thomas

Hi Alexander, Mathieu,

Just a quick bump for this issue. Can you shine a light on it?
Apperently Shapediver is not delivering the updated output of this ggIFc stream component.

IFC output will be the main product of my business, so I can’t go live until this is solved.
Thanks in advance for any help.

Best, Thomas

I could not reproduce this issue on my side yet. Is it possible for you to create a minimal file using the gglFc stream component, check whether you can reproduce the issue on this minimal file and then share it with me for testing?

Hi Mathieu,

I cut most unnecessary stuff out, which leaves me with this (just simple gridlines):

20220121 Moondoor grid maker minimal file.gh (23.7 KB)

I also iFramed this minimal file on my website:

By way of magic, I often found that the export was correct the first time, but wasn’t updated after this first configuration.

Thanks for your effort. Best, Thomas

@jonm at which point of the solution computation does the ggIFC stream component collect data? Likely the issue is rooted somewhere around this.

Geometry Gym IFC components don’t conform to typical Grasshopper conventions.
IFC has a primary hierarchy for the elements within (spatial breakdown), and an element has a mandatory host to be contained in a spatial element, or to decompose a parent element.
But years ago we decided to make the host element a mandatory input to a component, rather than require all the elements to be wired into a host. This is also because there is a secondary placement hierarchy where the product placement should be relative to it’s host. Rather than force users to comply with this, it’s easier to mask this (and other complexity) back of house.

Other reasons there are orphaned chains of components without a single root collector component, is that some users want to edit an existing ifc data set. Wiring all these changes into a single root component isn’t ideal.

So our work around at present is to force a staged solution. We have an event watcher and multiple steps to solving occurs, and the file stream is forced to delay until all other ggIFC components have solved.

If shape diver is looking for components with upstream data expiry, it might be never forcing our file stream component to recompute if it is orphaned.

I have considered a number of times a more typical approach, but have never really come up with an acceptable solution (ie in a bottom up approach, how do you warn a user an element isn’t wired into an appropriate host when you can’t detect that at compute time). And do you force any editing component to somehow be wired into a root component. We don’t treat the IFC objects as immutable and part of this is because of the multiple tiers of relationships (ie a material that is common to many elements).

I’m more than happy to discuss this. The streaming did work in SD when we looked at this but it was some time ago and perhaps there was subsequent changes that have stopped streaming to work.

Cheers,

Jon