Create instance - geometry does not match the original?
lorddayradon
Posts: 446
I'm laying down a modular street system. But every time I create an instance of one, the geometry is ascue.
The original is a single object, no bones or sub parts. It consists of three major planes, one for the road texture, and two for either side of the sidewalks, for the grass.
The original is on the left/ the instance is on the right. look at a side view at the sidewwalk between the grass plane (top) and road plane bottom.
You can see that the curb of the sidewalk is too high, and needs to come down a little. But doing this will cause the grass plane to drop even further away from the originals grass plane. It's the same with the road plane.
So I can either line up the grass and road, but have the sidewalk and curbs out of line verticaly or vice versa.
Shouldn't an instance of an object, replicate that object fully? I've tried a 180 rotation, just in case it's a model issue, and it makes no difference. I tried on create both, use defaults, and copy the original, but all lead to the same result.
Is there some sort of %error in instancing system that I'm not aware of?
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
They are instances not Geometry Shells? The latter have a Push Modifier applied on creation, expanding them slightly. Which set are the roads from?
edit: sorry mis-read that, yes they are instances. Making a 4 condo unit street scene, 1 original unit, 3 others as instances, and to help save on resources, instancing the terrain would help.
Is there any way to compensate for that while retaining the benefits of instancing?
set: https://www.daz3d.com/city-roads
I suppose I could manually create it all manualy if that would help, lay the grass tile, instance 15 times, and manually align, repeat for each. is fine for flat planes I suspect, but the sidewalks/curbs might not play nice with that either.
They ought to be identical, but I suppose there could be some kind of rounding error involved.
If you can't get the original unit to line up with the instances, how about burying the original somewhere way out of site (say at Y= -10000), and then composing your street only from instances?
[Added] I have that product, but couldn't reproduce your issue - an instanced road section lined up perfectly with its original. Could you post a simple duf file that shows your problem? Anyone with that product should be able to open it.
I used Section 2 from the props, isntanced it, copied the settings from the original and pasted them onto the copy (which is a 16cm Y Translation), and X translated it 1600CM - as far as I can see the two join prfectly.
instances don't load in the same spot as the originals, there are 2 choices given in the creation dialogue one they will have the same pivot unparented one they won't, I always mix it up but the geometry is the same, it also differs in position if instanced groups or parented props
Thank you all for the feedback and info. I'm totally invested in the project atm, and when you hit a wall like this it's very discouraging.
chris-2599934
That's what I thought, about the result I'm getting. To counter this I've just restarted as I leave my computer on indefinitely. Hopefully that will clear any residual problems related to corrupted memory or the like.
I mused on that while thinking about the issue after Richard's input, and my corrected reading comprehension. I think I'll save that as a last resort. (coincidentally) I suspect other instances of other objects are behaing the same way, though I have not tested/explored it. lining up walls with foundations, seems off. So that may be the option if the computer restart doesn't help.
Well that's encouraging. I hope it's not a case that the duf save series I'm working with corrupted earlier due to the long up time, and I have to start from scratch and save import sets.
Going to try that now, and will reply with results and duf if the issue persists.
Richard Haseltine
WendyLuvsCatz
Yes reading this brings some insight. I do have most objects in groups for organizational puposes. I also don't totally understand the "default settings" versus "copy original", but I suspect the later is what you mention first as it throws off those numbers Richard mentioned above.
I suspect that if all is well with a new duf trying to duplicate, if it suceeds (meaning I can't duplicate), I may have to unparent all the groups in the original duf, and test making new instances. if it fails, it will mean saving out prop sets of the originals, then loading them all into a new duf, and test making duplicates and thereby recreating the scene.
Well off to testing. Will know shortly with the basic test.
Ok a new duf seems to work.
Test 1
Process:
1. Load Section two
2. Convert All Surfaces to iray uber base, ignore images
3. Turn off geometry for: fence, fenceA, fenceAM
4. Creating instance - default settings.
5. Set translations y:16 x:1600
Result: everything seems normal.
Conclusion: PC needed restart or the duf I was working with was corrupted (not sure how that would effect instance creation though).
Test 2.
Process:
1. Open the duf I'm working with, it's like number 6 or 7 in a series of progressive saves.
2. Inspected the current content, It currently shows the same error as I showed above.
3. unparent original section2 from groups. Unchanged after.
4. delete section2 instance.
5. create instance of section2 - apply default settings
6. manually enter translation y:16 to match original position. IDENTICAL, hiding the instance shows no visual change
7. set instance translation x:1600
Results:
a) The road and grass planes line up perfectly.
b) the sidewalk and curbs, seem to be scaled up in the Y direction as before so the they don't line up vertically. tried 180d y rotation, no change
8. delete original and the instance.
9. repeat step #6, again it lines up perfectly and hiding the orginal shows no visual change.
10. repeat step #7
Results:
a) The road and grass planes line up perfectly.
b) the sidewalk and curbs, seem to be scaled up in the Y direction as before so the they don't line up vertically. tried 180d y rotation, no change
Conclusion:
Corrupted duf that is causing instance creation errors?
I am deleting all content from the duf, repeating test 1. Load section two, create instance with defaults, convert surfaces to daz Uber, hide the wall/fence.
Set y:16 - matches perfectly, set x:1600, y scale issue on sidewalk/curb portion.
Saving out the duf as a new one, and attaching.
Wierd that a duf can corrupt in a way that causes errors in instance creation. I don't understand that at all. Especially when loading in a new object and then instancing it.
Next steps I suppose.
1. Save out all the originals unparented as sets.
2. load them in a new duf and test instance creation.
-if that fails.
3. delete orginal, load a new one, instance, and see result.
EDIT: Richard, from your screen of you testing, all looks good, so does mine from that angle. Did you inspect from the other side at edges or from the side view? Looking say from uphill to down hill so to speak, all looks normal, but switching view to the other side shows the error as does a side view kinda between the road and grass planes.
Ok I'm totally baffled now.
Saved out my sets, file->new
Load section 2, create instance, set y16 all appears fine, set x1600, same issue.
-I skipped the shader conversion.
Restart daz just incase.
Load section 2, create instance, set y16 all appears fine, set x1600, same issue.
You can't see the issue as easily if you don't hide the wall (richard your screen is so distant from the seam of the original and the instance it would be hard to tell) further, I've set my orientation that same as your screen, and the furthest section on my screen is the instance (not sure which is which in yours) but in my setup the error is not visible because it's down hill and would need to rotate the view 180, or 90 at the seam to see it.
Starting to feel like I may have to resort to Chris's earlier suggestion for all my instances of everything
Gonna test that now and hope that two instances line up.
Ok I think I've got this figured out. It's an asset issue (intended at time of creation or not I don't know).
I got the same issue trying to line up two instances end to end, but not when they were in the same XYZ space.
So with one instance at x:1600, and the other at x:3200, I slowly scrolled back along the X in view, and the X trans of the second instance.
The closer I got instance two to x:1600 the smaller the difference got at the seam
This leads me to believe that when he created the curbs and rounded sidwalk edge for one side, one end is taller than the other, he then duplicated it, and rotated it 180d, offset it to create the space inbetween the side walk. Then just created the sidewalk by creating faces between the two.
This would explain why end to end they never line up, and why rotating it 180d has no effect. If both curbs/edges where slanted the same way it would work. but if each edge is slanted the oposite way, it never will.
Add in the wall, to cover up the issue with the sidewalk/curb edges, and all a person has to do is adjust/ensure the grass and road planes match. Most people may not notice that the sidewalk is off by a bit, mainly because it's directional dependent. uphill so to speak looking down, you'd never notice it especially from a distance, change your view 180d and you might see it if you're close enough. And most would just change their POV, asset cover ups, or adjust their scene to compensate.
OR...
It could be when he was lining up ends, he made sure that one end of section2 lined up with one end section3, but didn't realize that part of section3's end was off a bit and hence the error was introduced. so to speak. I could go into blender and fix it myself as I'm only using two sections (so far) for the two scenes I have, and I suspect that may be the only solution, and then recreating it in my scene proper.
And now the stewing contemplation: "And I paid for this."
HEY RICHARD!
If I go and fix then entire set so each end of each section perfectly matches up with each end of every other section, Can I sell it on daz as the "New and Improved City Roads"?
Oh and... If I delete the geometry for the fences in blender, would that have a greater impact on reduced resource usage when instancing it, compared to just setting the cutout geometry to 0 for them and then instancing? If I'm in blender anyway, it's no skin of my teeth to delete them.
And there we have it! a quick trip down to Blender inspection services.... and....
A vert at one end is y: 0.267284 m and the other vert at the other end that makes up the edge of that face is y: 0.283025 m
They should be identical. I suspect that Y and Z are likely off, as are the other verts that make up the ends that have the error.
HA, and the actual length is : 16.0021 m So I guess we need to set the x in Daz to +1600.21 for a proper end-to-end, I could fix that too or should we have a small overlap just to be safe?
edit: eww sneaky rat, the other end is 15.9979 m so the difference between the two is exactly 16m or 1600 in daz.
Yeah he was very meticulous in ensuring that each vert x location was identical, and only the Y and Z were off at each end on one side. Inspecting the other sidewalk, the numbers were virtually identical but for opposite ends, So it appears he simply duplicated then rotated the sidewalk he created 180d and slid it over but never ensured that each end pair of vertex ZY locations were identical before doing so.
Are there not folks that review this stuff for quality before it is approved and gets listed for sale? PITA that a consumer has to go and fix something he's bought before he can use it as advertised.
Further: I'm 100% now that he did the rotation slide thing. if you look at the set of vertex's for the four corners of the side walks, the diagnals are identical.
ie:
AB
CD
That length thing of 16m (1600 offset in daz)
A = 16.0021m and C= 15.9979
You would expect that A and B are the same, and C and D are the same with respective +/- coords but Noooo
A and D are the same, as B and C are the same with respective +/-, which indicates he simply rotated it, and it means that straight edge at the end of each sidewalk, is actually slanted, though both sides are exactly 16m, though not square and rather a parralellogram
Ok got section 2 fixed, here's the obj for any that want it.
Notes:
-grass, road, sidewalks have all been aligned (SQUARE) to line up perfectly no matter which way you rotate it, instance it, etc.
-I did not touch the roadside curbs ( a little variation never hurts)
-I did not touch the walls/fence, as they seem to be fine BUT... I'm not using them so I have no idea really
-I'm including a text file of the numbers I've used (just incase someone wants or needs to mod others to match) it's a little sparse in comments, but if you feel you're adept enough at blender to make the changes, then you should be able to figure it out. Especially inspecting the fixed obj.
-Lastly load the original, copy the surfaces, paste them on the fixed obj (daz uber convert if ya want), then save it out as a prop asset, or set asset,
edit: I should note that some vetex's where only out by 1/100K of a meter, while most were out by 1/100m upto 1/10m aproximately
Will be working on the T intersection #4 later as I'm using that also. Not going to post that unless there's a request. The straight road would be the most common that most people could use.
you cannot share the obj
however you can load it in morphloader and save and share that morph
Yeah, I'll just delete the obj that contains a mesh that has over 40 different vertex coordinates that make up over 60% of the total mesh. I'd rather let other purchasers remain the victims of shoddy Quality control and artists, do the work for themselves than do more work simply for them. But thanks for info.
I was just telling you the legal way to share it within the DAZ EULA
don't shoot the messenger
Sorry, I was not clear on exactly what was failing to match - and I wasn't sure I was using the right part. Yes, the mismatch is there in a newly downloaded copy of the model so please report it to support.
Sorry, "Hommy don't play dat" no more. I'm still waiting on acknowledgement and action on a 5-month-old ticket. I don't need more of those
Wendy, I wasn't shooting at you, I was pointing out the shortcomings of the individuals I pay money to.
Man the alignment of Section 4 (T intersection) with the straight road is so bad. I've fixed the sidewalk on the end facing me, but after I fix it on the other two ends, I'll actually have to touch the curbs.My bad, after digging into the vertex numbers more, it looks like he had the thing askew on all three axis's. I left it as they do line up, just not the prestine 1600
Given the amount of work you're doing.. Why not go the whole hog & create your own from scratch? Use PolyHaven CC0 textures and distribute your one through all the usual channels (hopefully as a freebie, but obviously that's up to you). It'll give you what you want, allow it to be exactly right and give others a tileable alternative that works.
Regards,
Richard.