hiding part of a merged object

[raft]

is it possible to make some part of an object invisible ? if we somehow now the polyon ids..

[EgonOlsen]

Not really...you can try to attach a vertex controller to it and move the vertices of the polygons that should be invisible out of sight. But that's pretty crude IMHO.

[raft]

i guess so. besides that, to hide 12 polygons, all merged structure's polygons will be uploaded again.

[EgonOlsen]

Yes, that's another issue....

[raft]

i've noticed, when merging objects polygons orders and count are preserved. for example, merging 10 poly + 15 poly + 25 poly results in an object with 50 polygons. and first 10 polygons come from first object, second 15 from second and so on. is this always the case, can we count on this ?

provided this is true (at least for some kind of objects), -if possible- adding a method to PolygonManager not to render some polygons can be extremely useful. for example, consumable level items can be merged into level and can be hidden after consumed.

[EgonOlsen]

You can't really do this for compiled objects. They compile down into several batches of geometry optimized by different criteria. Those batches could be rendered individually, but you don't have control about which geometry is in which batch. And splitting the batches by object doesn't do any good, because it destroys the advantages of merging.

[raft]

just for curiosity, how does dynamically compiled objects work then ? when some of their vertices are modified by a vertex controller, doesn't that require some of that vertices move among batches ?

[EgonOlsen]

No. Batching is done based on texture and blending modes, not on position in space. For simpler objects, the mapping is 1-to-1, for more complex ones, there's an additional index list that maps from the mesh to the compiled data. jPCT will print some messages about the mode it's using when compiling an animated object IIRC.

[raft]

i see. but doesn't changing texture or texture mode via PolygonManager requires batch change in this case ?

[EgonOlsen]

Yes, it would....but it's simply ignored for compiled objects. You can do that before the actual compilation happens, which is why AE's PolygonManager still has these methods. But after compilation, it will be ignored.

[raft]

i see. so there isn't much option left to handle many objects. i wanna try that crude option, at least for fun

so, what are the steps i should take ?
* i need to make the merged object compiled dynamically, but there is no such option in AE. (this works for Bones but i cant remember how)
* i need the polygons ids. see below
* move vertices out of sight via VertexController and call touch on object
* anything else ?

i've noticed, when merging objects polygons orders and count are preserved. for example, merging 10 poly + 15 poly + 25 poly results in an object with 50 polygons. and first 10 polygons come from first object, second 15 from second and so on. is this always the case, can we count on this ?

can i count on this ?

[EgonOlsen]

Yes, counts will be preserved. Dynamic compilation in AE happens on the fact that the object has an IVertexController (or an Animation) attached to it.

[raft]

yeap, the crude way is the way to go

here is a screenshot of an experimental large scene. ~750 objects are merged into two. it runs at more than 30fps


i was planning to merge consumable items in 50 or so batches to reduce vertex uploads but seems as it's not necessary. no noticable hickups when some vertices are pushed away. afterall it's not done every frame.

i've a few questions:
* how can i determine how many vertices an object will occupy when merged. Mesh().getUniqueVertexCount() does not give the correct number. for example, for a box created by primitives, this methods return 18. but it occupies only 10 vertices when merged.
* is there a best location to push unwanted vertices ? for example, does it matter to push them to same place or is it better to spread them ? besides this, i guess it's always better to push them somewhere behind Config.farPlane

[EgonOlsen]

Cool...

uniqueVertexCount should actually be giving you the correct number...it just adds the vertices of the bounding box to the mix, which is why you get 18 and not 10. Just subtract 8 from the returned value and it should be correct.

About the location...i think it's fine to push them all to one secret place. I don't see why this should be a problem.

[raft]

cool, thanks

indeed, i've found this technique so powerful that, you may want to add hide/ShowSubObject and/or translateSubObject methods to Object3D.