Problem with referenced DLVP

[Tom W.]

I have a model where some of the walls are clipped by Roof objects:

 

But when I bring the model into another file as a referenced DLVP I loose the clipping:

 

Why is it doing this? I've never created a referenced DLVP before but assumed it would mirror the original file exactly. I have got around this by creating a 2nd model with lowered unclipped walls for the purposes of importing into my site model file but would be preferable not to have to do this... It means I have one model for construction drawings + a second one for placing in the landscape...

 

Thanks

[Boh]

My first thought is have you done a save with the file being referenced and then updated the reference?

Edited May 31, 2021 by Boh

[Tom W.]

Ok I've resolved the projecting-through-the-roof walls, now my DLVP looks like this!:

 

When I've had this before I've restarted VW + it's gone away but not this time.

 

So next step: save the model as a symbol instead. I import it into the site model file + for some reason some of the wall components are missing + the blue part of the solar panels!:

 

This is in OpenGL. If I render it in Final Quality they come back:

 

Not sure what the hell's going on I will try shutting down the computer + creating new files...☹️

 

[Tom W.]

2 minutes ago, Boh said:

My first thought is have you done a save with the file being referenced and then updated the reference?

 

Oo thanks I will try this

[Tom W.]

10 minutes ago, Boh said:

My first thought is have you done a save with the file being referenced and then updated the reference?

Ok I've gone through the process of creating the referenced DLVP again but in a new site model file + it came in fine: without the too-high walls. Phew. Not sure why it didn't do it the first time but anyway my faith in VW has been restored somewhat.

 

However I zoom around a bit + the weird cross-hatching thing comes back. But this time I close the file + reopen it + it's gone. Phew. Until I try to do anything in the file + it comes back!:

 

Close file + reopen it + it's fine again:

 

Any thoughts? Crease angle has no effect. I feel like I've upset VW today - I didn't mean to!

 

Thanks

[Boh]

One of your screen shots showed your dlvp some distance from the origin, which may mean the model in the ref file is also some distance away.

 

Suggest you bring things closer to home then see if the probs are still there. 

[Tom W.]

@Boh you're a genius. I was just about to send a long reply explaining that although my user origin was 578-odd km away my internal origin was only 150m from the geometry so all was correctly set up. But then I re-read your post + you're absolutely right. The model was NOT created in a georeferenced file so User Origin + Internal Origin were both at 0,0. So when I created the DLVP it came into the site model file at 0,0 + I had to move it the 578km to where the site model was. So although this resulted in all the geometry in the file all being located within a couple of hundred metres of the internal origin, because the DLVP is referencing a file where the internal origin is still 578km away this will create problems? So I need to move the Internal Origin in the referenced file so that it corresponds (more or less) to that in the georeferenced site model file?

 

It's funny because I noticed that my DLVPs at one point had enormous bounding boxes - the object in one corner then the rest of the box stretching miles off in the other direction - so presumably this was the DLVP struggling to comprehend why it was so far from home?

 

Thanks for your suggestions!

Edited May 31, 2021 by Tom W.

[Boh]

Haha unfortunately I’m not a genius. Just someone who happened to have pretty much the exact same issue just last week 😁. It only took me 3 hours to realise there was a toilet symbol pasted into the file 30km from the origin...

 

I saw the rendering issue which made me suspect this was the issue then saw the x/y coordinates of your symbol screen shot. Glad you got it sorted!

Edited May 31, 2021 by Boh

[Tom W.]

Ok so I moved the Internal Origin in the referenced file so that it had more or less the same location as the internal origin in the site model file, assuming that the different in Internal Origin locations between the two files was causing the graphical issues. No return of the cross-hatching so far.

 

But the original issue I posted about - the walls sticking up through the roof - is still present. I thought it had gone away but realised my DLVP was referencing a modified version of the file + not the original preferred one. So it would just be good to know from someone why this might be happening? @Matt Panzer??? (sorry!) I tried what @Boh suggested - saving the referenced file then updating the reference - but this had no effect. It still looks like this:

 

 

Walls which are clipped by Roof objects in the referenced file are no longer clipped in the DLVP.

 

It would just be good to know why this is as although I have got around the issue by creating a modified version of the file where I've lowered the walls this isn't ideal because it means I have to keep two versions of the model on the go at once...

 

Are there any other things which can get lost in translation when you create a referenced DLVP? If I create a DLVP of the model within the same file it displays correctly so it's something to do with referencing it???

 

Thanks

 

 

[Matt Panzer]

Hi @Tom W.,

Can you send me the files privately?

[Tom W.]

yep will do many thanks

[Boh]

Referenced files are linked by their file name and their location. So if you change the name or location you lose the link. I suspect at some point you did a save as and renamed the file or changed its location. The reference will still be looking at the original file/location rather than the saved as one.

[Tom W.]

Thanks @Boh the DLVP came into the file looking like this from the off, and was the same every other time I tried it using new files. @Matt Panzer  looked at the files + said:

 

"I see no reason this would be happening. I submitted bug VB-179323 for this and directed it to the appropriate engineer."

 

So that's that! At least I learnt about the whole make-sure-the-internal-origin-in-the-first-file-is-within-proximity-of-the-internal-origin-in-the-second-file thing so thanks again for putting me onto that.

[Boh]

Ok that's wierd. Glad you got the @Matt Panzer onto it!