<div dir="ltr">thanks Brecht, looks like a good idea, gonna try to apply it.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 11, 2016 at 2:13 PM, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Things do indeed get more complicated in that case. In Blender we<br>
don't have custom animated normals as far as I know, so it's not an<br>
issue we have to deal with. You could try to delay the splitting until<br>
after motion blur data has been exported, storing the normals per<br>
corner as an intermediate step and splitting at the end when you have<br>
all the information.<br>
<div class="HOEnZb"><div class="h5"><br>
On Sat, Jun 11, 2016 at 12:11 PM, Mohamed Sakr <<a href="mailto:3dsakr@gmail.com">3dsakr@gmail.com</a>> wrote:<br>
> by mesh topology changes here I don't mean point/poly count, I mean just<br>
> shapes (so normals changes)<br>
><br>
> On Sat, Jun 11, 2016 at 12:10 PM, Mohamed Sakr <<a href="mailto:3dsakr@gmail.com">3dsakr@gmail.com</a>> wrote:<br>
>><br>
>> hmm, good point :)<br>
>> my only concern here is: when you do a motion blur, and the mesh topology<br>
>> changes, what if point count changed? "due to normals split"., how you gonna<br>
>> export the motion blur data? (the ugly way via tracking main frame mesh<br>
>> points using a map, but not optimal).<br>
>><br>
>> On Sat, Jun 11, 2016 at 11:05 AM, Brecht Van Lommel<br>
>> <<a href="mailto:brechtvanlommel@pandora.be">brechtvanlommel@pandora.be</a>> wrote:<br>
>>><br>
>>> It depends on the specific mesh which is more memory efficient. I<br>
>>> expect that in the typical case only a small number of vertices needs<br>
>>> to be split, and the extra memory ends up being smaller than the extra<br>
>>> memory required for storing all normals per corner. Game engines do<br>
>>> such splitting too, but for all attributes including UVs, that would<br>
>>> likely reduce memory usage further.<br>
>>><br>
>>> On Sat, Jun 11, 2016 at 4:12 AM, Mohamed Sakr <<a href="mailto:3dsakr@gmail.com">3dsakr@gmail.com</a>> wrote:<br>
>>> > Hi,<br>
>>> ><br>
>>> > I'm wondering why Mesh point normals attribute "aka<br>
>>> > ATTR_STD_VERTEX_NORMAL"<br>
>>> > is per vertex not per corner, why not making it a corner and avoid the<br>
>>> > point<br>
>>> > splitting? wouldn't this make mesh more consistent and using less<br>
>>> > memory??<br>
>>> > please advise.<br>
>>> ><br>
>>> > cheers,<br>
>>> > Mohamed Sakr<br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > Bf-cycles mailing list<br>
>>> > <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
>>> > <a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
>>> ><br>
>>> _______________________________________________<br>
>>> Bf-cycles mailing list<br>
>>> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
>>> <a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> Bf-cycles mailing list<br>
> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
> <a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
><br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</div></div></blockquote></div><br></div>