Ya, you are right. The difference is because it still using the generator.
But the UV-map problems still there, so I believe we still need to clean
it up.
Regards,
Halfdan Ingvarsson wrote:
> This is not a valid comparison at all.
>
> First of all, for the "Original" object no geometry is saved to disk.
Only the parameters for the sphere polymesh generator. All the breakup
sphere objects are frozen objects that hold actual geometry.
>
> If you freeze the sphere and then export it, you'll notice the size
difference is around two times (594Kb vs 1125Kb), rather than one
hundred.
>
> The overhead of the breakup model, on the frozen sphere model, is the
addition of 99 individual kinematic and visibility properties + some
extra bits.
>
> - ½
>
>
>
>> -----Original Message-----
>> From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM]On Behalf
>> Of misterdi(at)cbn.net.id
>> Sent: Tuesday, 09 May, 2006 15:04
>> To: XSI(at)Softimage.COM
>> Subject: Re: file size difference
>>
>>
>> Hmmm, I think it's more than just a problem with the UV, even without
>> the UV you could easily blow up the scene size.
>>
>> This is an example of a JScript to create the REPRO:
>> =================================================
>>
>> NewScene(null, false);
>> CreatePrim("Sphere", "MeshSurface", null, null);
>> SetValue("sphere.polymsh.geom.subdivu", 100, null);
>> SetValue("sphere.polymsh.geom.subdivv", 100, null);
>> CreateModel("Sphere", "Original", null, null);
>> CreatePrim("Sphere", "MeshSurface", null, null);
>> SetValue("sphere.polymsh.geom.subdivu", 100, null);
>> SetValue("sphere.polymsh.geom.subdivv", 100, null);
>> var genObj = "";
>> for (i = 0; i<100; i++) {
>> var j1 = i * 100;
>> var j2 = (i + 1) * 100 - 1;
>> var parts = "sphere.poly[" + j1 + "-" + j2 + "]";
>> var dummy = new ActiveXObject("XSI.Collection");
>> SelectGeometryComponents(parts);
>> dummy = ExtractFromComponents("ExtractPolygonsOp", "", "part", false,
>> siImmediateOperation, siKeepGenOpInputs, null);
>> if (i == 0)
>> {
>> genObj = dummy(0);
>> }
>> else
>> {
>> genObj = genObj + "," + dummy(0);
>> }
>> }
>> CreateModel(genObj, "Breakup", null, null);
>> DeleteObj("sphere");
>>
>> =================================================
>>
>> What the script does is create a 2 similar model :
>> 1. Original is a model that hold a sphere with 100 x 100 subdivision
>> 2. Breakup is a model that hold 100 part of a sphere with 1 x 100
>> subdivision.
>>
>> The breakup was created using extract polygons in immidiate mode so no
>> history is involved and no UVdata in both. It also sharing the same
>> default material so it doesn't create a redundant data there.
>>
>> Export Original and Breakup with Export->Model and look at the difference
>> of the file size.
>> I can understand if the Breakup.emdl should be larger then Original.emdl,
>> A factor of 4 to 5 times is acceptable, but a factor of 100 times is
>> definitely un-acceptable.
>>
>> Becareful with line breaks.
>>
>>
>> Stefan Andersson wrote:
>>
>>
>>
>>> I've had the same problem too many times now. And it always happens
>>> when dealing with ZBrush geometry. For some reason the UV
>>
>> get's messed
>>
>>
>>> up and causes that geometry to grow in size.
>>> It seems to be linked to images, once a image is lost the UV might
>>> think (dont ask me how) that the image may be millions of pixels
>>> wide...
>>>
>>> Anyhow, I've sent the files in to support and they are
>>
>> working on it.
>>
>>
>>> One workaround as Andy said is to copy/paste the UV's. (or let the
>>> object take a tour on the dotXSI bus.. hehe)
>>>
>>> regards
>>> stefan andersson
>>>
>>>
>>> On 5/6/06, Syah Inderaprana <jindol(at)frameworks-studios.com> wrote:
>>>
>>>
>>>
>>>>> Hi Syah,
>>>>>
>>>>> There is a recognised bug with UVs, in that they can occasionally
>>>>>
>>>>
>>>> cause
>>>>
>>>>
>>>>> scene bloat. To my knowledge, Softimage haven't found a way to
>>>>>
>>>>
>>>> reproduce
>>>>
>>>>
>>>>> this problem so they've not been able to fix it yet.
>>>>>
>>>>> The way to fix it (assuming that this is the cause of the problem
>>>>>
>>>>
>>>> you're
>>>>
>>>>
>>>>> having), is to add a new set of UVs, and copy and paste the UVs
>>>>>
>>>>
>>>> from the
>>>>
>>>>
>>>>> old
>>>>> set to the new set (in the Texture Editor). You can then
>>
>> delete the
>>
>>
>>>> old UV
>>>>
>>>>
>>>>> property, and that should hopefully fix it.
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>
>>>> Thanks,
>>>> I'll try that ...
>>>>
>>>>
>>>> --
>>>> Syah Inderaprana
>>>> Infinite Frameworks Studios
>>>> Batam, Indonesia
>>>>
>>>> ---
>>>> Unsubscribe? Mail Majordomo(at)Softimage.COM with the
>>
>> following text in
>>
>>
>>>> body:
>>>> unsubscribe xsi
>>>>
>>>>
>>>
>>> --
>>> -------------------[ tear off and keep ]-------------------
>>> http://os3d.blogspot.com/
>>> http://www.flickr.com/photos/sanders3d/
>>>
>>> ---
>>> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
>>> body:
>>> unsubscribe xsi
>>>
>>>
>>>
>>
>> ---
>> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
>> unsubscribe xsi
>>
>>
>
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> unsubscribe xsi
>
>
>
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
