I wonder if anyone can give me some advice here. I'm trying to make an
editor that just allows users to move vertices around (for now at
least).
My specific problem is keeping track of vertices. I have a cube around
each model vertex, and am testing for collisions between the cube
faces and the mouse ray. The user drags the mouse around and the
program updates the vertex coordinates (don't know quite how yet),
then calls updateVAR on the relevant Part.
The file loading code runs updateAll, and then has to go through the
vertex array of each Part and do a proximity test with each of the
coordinates actually given to the articulated model, to work out which
of the vertices in the file corresponds with which in the articulated
model (and which vertices correspond to the small cubes). What seems
to have happened is that some vertices have been duplicated; I think
this has something to do with Meld but am not sure. With this
happening, I can't work out simply which vertices need to be moved
when.
So, can I stop the library from changing the vertex array when
updateAll is called? If not, is there some other way of working out
which vertices in the array need changing? The current method is
unsurprisingly extremely slow.
The response from morgan was to set the normalsmoothingangle and vertex
weldradius to 0 in the articulatedmodel weld settings if you don't want the
vertices touched on load.
corey
On Sep 29, 2009 6:18 PM, "Andy H" <andyhowl...@googlemail.com> wrote:
I wonder if anyone can give me some advice here. I'm trying to make an
editor that just allows users to move vertices around (for now at
least).
My specific problem is keeping track of vertices. I have a cube around
each model vertex, and am testing for collisions between the cube
faces and the mouse ray. The user drags the mouse around and the
program updates the vertex coordinates (don't know quite how yet),
then calls updateVAR on the relevant Part.
The file loading code runs updateAll, and then has to go through the
vertex array of each Part and do a proximity test with each of the
coordinates actually given to the articulated model, to work out which
of the vertices in the file corresponds with which in the articulated
model (and which vertices correspond to the small cubes). What seems
to have happened is that some vertices have been duplicated; I think
this has something to do with Meld but am not sure. With this
happening, I can't work out simply which vertices need to be moved
when.
So, can I stop the library from changing the vertex array when
updateAll is called? If not, is there some other way of working out
which vertices in the array need changing? The current method is
unsurprisingly extremely slow.
Hi, thanks for the reply from whoever it was who gave it!
I am still having problems though - the weld process, with these
settings, splits up every vertex into multiple ones. What I want is
for no vertices to be touched at all - my input list does not have 3
unique vertices per face, many are shared.
I could use a method that does not split any up. Looking at the
process function, it seems I want normalSmoothingAngle to be used to
determine where normals are smoothed, and then later on for vertices
to be welded always whenever they are in the same location - I am not
sure if this makes any sense, as you'd need to have planes store
normals, not vertices, and possibly G3D works with vertex normals...
I'm a bit out of my depth here! I tried setting the smoothing angle to
180 in the hope that all vertices in a certain position would be
welded, but it didn't seem to work.
Alternatively I could use a method that can work out which vertices in
the new list are equivalent to a certain one in the old list. I
thought about it but I don't understand how the vertex ordering (and
repeating) is determined after processing.
More info would be much appreciated.
On Oct 1, 4:53 pm, corey taylor <corey.tay...@gmail.com> wrote:
> The response from morgan was to set the normalsmoothingangle and vertex
> weldradius to 0 in the articulatedmodel weld settings if you don't want the
> vertices touched on load.
> I wonder if anyone can give me some advice here. I'm trying to make an
> editor that just allows users to move vertices around (for now at
> least).
> My specific problem is keeping track of vertices. I have a cube around
> each model vertex, and am testing for collisions between the cube
> faces and the mouse ray. The user drags the mouse around and the
> program updates the vertex coordinates (don't know quite how yet),
> then calls updateVAR on the relevant Part.
> The file loading code runs updateAll, and then has to go through the
> vertex array of each Part and do a proximity test with each of the
> coordinates actually given to the articulated model, to work out which
> of the vertices in the file corresponds with which in the articulated
> model (and which vertices correspond to the small cubes). What seems
> to have happened is that some vertices have been duplicated; I think
> this has something to do with Meld but am not sure. With this
> happening, I can't work out simply which vertices need to be moved
> when.
> So, can I stop the library from changing the vertex array when
> updateAll is called? If not, is there some other way of working out
> which vertices in the array need changing? The current method is
> unsurprisingly extremely slow.
Looking at the source for ArticulatedModel, it looks like you could just
call computeBounds and updateVAR instead of updateAll and get the effect you
want. The normals won't be right, though--by definition, you can't update
the normals in place since you'd have to break some vertices to do it right.
On Sat, Oct 3, 2009 at 3:07 PM, Andy H <andyhowl...@googlemail.com> wrote:
> Hi, thanks for the reply from whoever it was who gave it!
> I am still having problems though - the weld process, with these
> settings, splits up every vertex into multiple ones. What I want is
> for no vertices to be touched at all - my input list does not have 3
> unique vertices per face, many are shared.
> I could use a method that does not split any up. Looking at the
> process function, it seems I want normalSmoothingAngle to be used to
> determine where normals are smoothed, and then later on for vertices
> to be welded always whenever they are in the same location - I am not
> sure if this makes any sense, as you'd need to have planes store
> normals, not vertices, and possibly G3D works with vertex normals...
> I'm a bit out of my depth here! I tried setting the smoothing angle to
> 180 in the hope that all vertices in a certain position would be
> welded, but it didn't seem to work.
> Alternatively I could use a method that can work out which vertices in
> the new list are equivalent to a certain one in the old list. I
> thought about it but I don't understand how the vertex ordering (and
> repeating) is determined after processing.
> More info would be much appreciated.
> On Oct 1, 4:53 pm, corey taylor <corey.tay...@gmail.com> wrote:
> > This thread was lost.
> > The response from morgan was to set the normalsmoothingangle and vertex
> > weldradius to 0 in the articulatedmodel weld settings if you don't want
> the
> > vertices touched on load.
> > I wonder if anyone can give me some advice here. I'm trying to make an
> > editor that just allows users to move vertices around (for now at
> > least).
> > My specific problem is keeping track of vertices. I have a cube around
> > each model vertex, and am testing for collisions between the cube
> > faces and the mouse ray. The user drags the mouse around and the
> > program updates the vertex coordinates (don't know quite how yet),
> > then calls updateVAR on the relevant Part.
> > The file loading code runs updateAll, and then has to go through the
> > vertex array of each Part and do a proximity test with each of the
> > coordinates actually given to the articulated model, to work out which
> > of the vertices in the file corresponds with which in the articulated
> > model (and which vertices correspond to the small cubes). What seems
> > to have happened is that some vertices have been duplicated; I think
> > this has something to do with Meld but am not sure. With this
> > happening, I can't work out simply which vertices need to be moved
> > when.
> > So, can I stop the library from changing the vertex array when
> > updateAll is called? If not, is there some other way of working out
> > which vertices in the array need changing? The current method is
> > unsurprisingly extremely slow.
> Looking at the source for ArticulatedModel, it looks like you could just
> call computeBounds and updateVAR instead of updateAll and get the effect you
> want. The normals won't be right, though--by definition, you can't update
> the normals in place since you'd have to break some vertices to do it right.
> -m
> On Sat, Oct 3, 2009 at 3:07 PM, Andy H <andyhowl...@googlemail.com> wrote:
> > Hi, thanks for the reply from whoever it was who gave it!
> > I am still having problems though - the weld process, with these
> > settings, splits up every vertex into multiple ones. What I want is
> > for no vertices to be touched at all - my input list does not have 3
> > unique vertices per face, many are shared.
> > I could use a method that does not split any up. Looking at the
> > process function, it seems I want normalSmoothingAngle to be used to
> > determine where normals are smoothed, and then later on for vertices
> > to be welded always whenever they are in the same location - I am not
> > sure if this makes any sense, as you'd need to have planes store
> > normals, not vertices, and possibly G3D works with vertex normals...
> > I'm a bit out of my depth here! I tried setting the smoothing angle to
> > 180 in the hope that all vertices in a certain position would be
> > welded, but it didn't seem to work.
> > Alternatively I could use a method that can work out which vertices in
> > the new list are equivalent to a certain one in the old list. I
> > thought about it but I don't understand how the vertex ordering (and
> > repeating) is determined after processing.
> > More info would be much appreciated.
> > On Oct 1, 4:53 pm, corey taylor <corey.tay...@gmail.com> wrote:
> > > This thread was lost.
> > > The response from morgan was to set the normalsmoothingangle and vertex
> > > weldradius to 0 in the articulatedmodel weld settings if you don't want
> > the
> > > vertices touched on load.
> > > I wonder if anyone can give me some advice here. I'm trying to make an
> > > editor that just allows users to move vertices around (for now at
> > > least).
> > > My specific problem is keeping track of vertices. I have a cube around
> > > each model vertex, and am testing for collisions between the cube
> > > faces and the mouse ray. The user drags the mouse around and the
> > > program updates the vertex coordinates (don't know quite how yet),
> > > then calls updateVAR on the relevant Part.
> > > The file loading code runs updateAll, and then has to go through the
> > > vertex array of each Part and do a proximity test with each of the
> > > coordinates actually given to the articulated model, to work out which
> > > of the vertices in the file corresponds with which in the articulated
> > > model (and which vertices correspond to the small cubes). What seems
> > > to have happened is that some vertices have been duplicated; I think
> > > this has something to do with Meld but am not sure. With this
> > > happening, I can't work out simply which vertices need to be moved
> > > when.
> > > So, can I stop the library from changing the vertex array when
> > > updateAll is called? If not, is there some other way of working out
> > > which vertices in the array need changing? The current method is
> > > unsurprisingly extremely slow.
This isn't a G3D limitation, it is a math problem I'm talking about.
"Smooth" surfaces are approximated (on GPUs) by creating faceted surfaces
that have artificial surface normals called vertex normals placed at the
vertices. The surface normal used for shading then varies linearly
(Barycentrically) across the actual triangle. These vertex normals are
typically computed as some average of the true face normals for adjacent
faces.
In order to make the smooth surface actually look good, at a single point in
space you need to have all of the vertex normals be the same. This is
typically done by having a single "vertex" with a single "vertex normal" at
that point in space, and defining an index triangle mesh over those
vertices. The problem with this representation is that you can't now move
two adjacent faces apart--they are defined by their shared vertices. So
this is good for rendering and bad for modeling (and physics).
There are a few things you can do to work around this:
1. Model all faces with unique vertices and manually compute the vertex
normals, ensuring that they are identical at colocated vertices. I think it
will be hard to do this fast.
2. Disallow topology changes (or let them be expensive) in your modeler.
You can then compute the adjacency information once (using MeshAlg) and
recompute the vertex normals cheaply using the adjacent face list for each
vertex.
3. Go back to option 1, but only show flat shading (which is what a lot of
modelers do!) so that you don't have to compute vertex normals.
Personally, I'd do option 3 because maintaining adjacency code is not a fun
thing to program. But you may really want the appearance of curved surfaces
while they are being manipulated.
On Wed, Oct 14, 2009 at 1:49 PM, Andy H <andyhowl...@googlemail.com> wrote:
> There's no way I can insist that everything is welded and smoothed?
> On Oct 4, 2:41 am, Morgan McGuire <morga...@gmail.com> wrote:
> > Looking at the source for ArticulatedModel, it looks like you could just
> > call computeBounds and updateVAR instead of updateAll and get the effect
> you
> > want. The normals won't be right, though--by definition, you can't
> update
> > the normals in place since you'd have to break some vertices to do it
> right.
> > -m
> > On Sat, Oct 3, 2009 at 3:07 PM, Andy H <andyhowl...@googlemail.com>
> wrote:
> > > Hi, thanks for the reply from whoever it was who gave it!
> > > I am still having problems though - the weld process, with these
> > > settings, splits up every vertex into multiple ones. What I want is
> > > for no vertices to be touched at all - my input list does not have 3
> > > unique vertices per face, many are shared.
> > > I could use a method that does not split any up. Looking at the
> > > process function, it seems I want normalSmoothingAngle to be used to
> > > determine where normals are smoothed, and then later on for vertices
> > > to be welded always whenever they are in the same location - I am not
> > > sure if this makes any sense, as you'd need to have planes store
> > > normals, not vertices, and possibly G3D works with vertex normals...
> > > I'm a bit out of my depth here! I tried setting the smoothing angle to
> > > 180 in the hope that all vertices in a certain position would be
> > > welded, but it didn't seem to work.
> > > Alternatively I could use a method that can work out which vertices in
> > > the new list are equivalent to a certain one in the old list. I
> > > thought about it but I don't understand how the vertex ordering (and
> > > repeating) is determined after processing.
> > > More info would be much appreciated.
> > > On Oct 1, 4:53 pm, corey taylor <corey.tay...@gmail.com> wrote:
> > > > This thread was lost.
> > > > The response from morgan was to set the normalsmoothingangle and
> vertex
> > > > weldradius to 0 in the articulatedmodel weld settings if you don't
> want
> > > the
> > > > vertices touched on load.
> > > > I wonder if anyone can give me some advice here. I'm trying to make
> an
> > > > editor that just allows users to move vertices around (for now at
> > > > least).
> > > > My specific problem is keeping track of vertices. I have a cube
> around
> > > > each model vertex, and am testing for collisions between the cube
> > > > faces and the mouse ray. The user drags the mouse around and the
> > > > program updates the vertex coordinates (don't know quite how yet),
> > > > then calls updateVAR on the relevant Part.
> > > > The file loading code runs updateAll, and then has to go through the
> > > > vertex array of each Part and do a proximity test with each of the
> > > > coordinates actually given to the articulated model, to work out
> which
> > > > of the vertices in the file corresponds with which in the articulated
> > > > model (and which vertices correspond to the small cubes). What seems
> > > > to have happened is that some vertices have been duplicated; I think
> > > > this has something to do with Meld but am not sure. With this
> > > > happening, I can't work out simply which vertices need to be moved
> > > > when.
> > > > So, can I stop the library from changing the vertex array when
> > > > updateAll is called? If not, is there some other way of working out
> > > > which vertices in the array need changing? The current method is
> > > > unsurprisingly extremely slow.
Actually I don't want any smoothing at all. So what about this:
Process the file with my own code (with the shared vertices) to
generate a list of non-shared ones. Feed this into the program, asking
it to calculate normals and do no smoothing or welding whatsoever.
This way the list in the model after updating is the same as the one I
have, and changing vertex positions is easy (possibly changing normals
too?).
The only problem with this is that I couldn't see a way to stop
welding when two surfaces were at exactly the same angle, i.e. flat (I
think that was the issue anyway). Is there a way to deal with this?
Thanks for the help so far,
Andy
On Oct 14, 7:03 pm, Morgan McGuire <morga...@gmail.com> wrote:
> This isn't a G3D limitation, it is a math problem I'm talking about.
> "Smooth" surfaces are approximated (on GPUs) by creating faceted surfaces
> that have artificial surface normals called vertex normals placed at the
> vertices. The surface normal used for shading then varies linearly
> (Barycentrically) across the actual triangle. These vertex normals are
> typically computed as some average of the true face normals for adjacent
> faces.
> In order to make the smooth surface actually look good, at a single point in
> space you need to have all of the vertex normals be the same. This is
> typically done by having a single "vertex" with a single "vertex normal" at
> that point in space, and defining an index triangle mesh over those
> vertices. The problem with this representation is that you can't now move
> two adjacent faces apart--they are defined by their shared vertices. So
> this is good for rendering and bad for modeling (and physics).
> There are a few things you can do to work around this:
> 1. Model all faces with unique vertices and manually compute the vertex
> normals, ensuring that they are identical at colocated vertices. I think it
> will be hard to do this fast.
> 2. Disallow topology changes (or let them be expensive) in your modeler.
> You can then compute the adjacency information once (using MeshAlg) and
> recompute the vertex normals cheaply using the adjacent face list for each
> vertex.
> 3. Go back to option 1, but only show flat shading (which is what a lot of
> modelers do!) so that you don't have to compute vertex normals.
> Personally, I'd do option 3 because maintaining adjacency code is not a fun
> thing to program. But you may really want the appearance of curved surfaces
> while they are being manipulated.
> -m
> On Wed, Oct 14, 2009 at 1:49 PM, Andy H <andyhowl...@googlemail.com> wrote:
> > There's no way I can insist that everything is welded and smoothed?
> > On Oct 4, 2:41 am, Morgan McGuire <morga...@gmail.com> wrote:
> > > Looking at the source for ArticulatedModel, it looks like you could just
> > > call computeBounds and updateVAR instead of updateAll and get the effect
> > you
> > > want. The normals won't be right, though--by definition, you can't
> > update
> > > the normals in place since you'd have to break some vertices to do it
> > right.
> > > -m
> > > On Sat, Oct 3, 2009 at 3:07 PM, Andy H <andyhowl...@googlemail.com>
> > wrote:
> > > > Hi, thanks for the reply from whoever it was who gave it!
> > > > I am still having problems though - the weld process, with these
> > > > settings, splits up every vertex into multiple ones. What I want is
> > > > for no vertices to be touched at all - my input list does not have 3
> > > > unique vertices per face, many are shared.
> > > > I could use a method that does not split any up. Looking at the
> > > > process function, it seems I want normalSmoothingAngle to be used to
> > > > determine where normals are smoothed, and then later on for vertices
> > > > to be welded always whenever they are in the same location - I am not
> > > > sure if this makes any sense, as you'd need to have planes store
> > > > normals, not vertices, and possibly G3D works with vertex normals...
> > > > I'm a bit out of my depth here! I tried setting the smoothing angle to
> > > > 180 in the hope that all vertices in a certain position would be
> > > > welded, but it didn't seem to work.
> > > > Alternatively I could use a method that can work out which vertices in
> > > > the new list are equivalent to a certain one in the old list. I
> > > > thought about it but I don't understand how the vertex ordering (and
> > > > repeating) is determined after processing.
> > > > More info would be much appreciated.
> > > > On Oct 1, 4:53 pm, corey taylor <corey.tay...@gmail.com> wrote:
> > > > > This thread was lost.
> > > > > The response from morgan was to set the normalsmoothingangle and
> > vertex
> > > > > weldradius to 0 in the articulatedmodel weld settings if you don't
> > want
> > > > the
> > > > > vertices touched on load.
> > > > > I wonder if anyone can give me some advice here. I'm trying to make
> > an
> > > > > editor that just allows users to move vertices around (for now at
> > > > > least).
> > > > > My specific problem is keeping track of vertices. I have a cube
> > around
> > > > > each model vertex, and am testing for collisions between the cube
> > > > > faces and the mouse ray. The user drags the mouse around and the
> > > > > program updates the vertex coordinates (don't know quite how yet),
> > > > > then calls updateVAR on the relevant Part.
> > > > > The file loading code runs updateAll, and then has to go through the
> > > > > vertex array of each Part and do a proximity test with each of the
> > > > > coordinates actually given to the articulated model, to work out
> > which
> > > > > of the vertices in the file corresponds with which in the articulated
> > > > > model (and which vertices correspond to the small cubes). What seems
> > > > > to have happened is that some vertices have been duplicated; I think
> > > > > this has something to do with Meld but am not sure. With this
> > > > > happening, I can't work out simply which vertices need to be moved
> > > > > when.
> > > > > So, can I stop the library from changing the vertex array when
> > > > > updateAll is called? If not, is there some other way of working out
> > > > > which vertices in the array need changing? The current method is
> > > > > unsurprisingly extremely slow.
> Actually I don't want any smoothing at all. So what about this:
> Process the file with my own code (with the shared vertices) to
> generate a list of non-shared ones. Feed this into the program, asking
> it to calculate normals and do no smoothing or welding whatsoever.
> This way the list in the model after updating is the same as the one I
> have, and changing vertex positions is easy (possibly changing normals
> too?).
If you don't want smoothing, calculating your own normals is very easy :)
So you can just call updateVAR and it will use the normals you computed.
> The only problem with this is that I couldn't see a way to stop
> welding when two surfaces were at exactly the same angle, i.e. flat (I
> think that was the issue anyway). Is there a way to deal with this?
The weld doesn't run unless you call updateAll. And you can control it with
ArticulatedModel::Settings::Weld anyway to turn off vertex welding.
> On Oct 14, 7:03 pm, Morgan McGuire <morga...@gmail.com> wrote:
> > This isn't a G3D limitation, it is a math problem I'm talking about.
> > "Smooth" surfaces are approximated (on GPUs) by creating faceted surfaces
> > that have artificial surface normals called vertex normals placed at the
> > vertices. The surface normal used for shading then varies linearly
> > (Barycentrically) across the actual triangle. These vertex normals are
> > typically computed as some average of the true face normals for adjacent
> > faces.
> > In order to make the smooth surface actually look good, at a single point
> in
> > space you need to have all of the vertex normals be the same. This is
> > typically done by having a single "vertex" with a single "vertex normal"
> at
> > that point in space, and defining an index triangle mesh over those
> > vertices. The problem with this representation is that you can't now
> move
> > two adjacent faces apart--they are defined by their shared vertices. So
> > this is good for rendering and bad for modeling (and physics).
> > There are a few things you can do to work around this:
> > 1. Model all faces with unique vertices and manually compute the vertex
> > normals, ensuring that they are identical at colocated vertices. I think
> it
> > will be hard to do this fast.
> > 2. Disallow topology changes (or let them be expensive) in your modeler.
> > You can then compute the adjacency information once (using MeshAlg) and
> > recompute the vertex normals cheaply using the adjacent face list for
> each
> > vertex.
> > 3. Go back to option 1, but only show flat shading (which is what a lot
> of
> > modelers do!) so that you don't have to compute vertex normals.
> > Personally, I'd do option 3 because maintaining adjacency code is not a
> fun
> > thing to program. But you may really want the appearance of curved
> surfaces
> > while they are being manipulated.
> > -m
> > On Wed, Oct 14, 2009 at 1:49 PM, Andy H <andyhowl...@googlemail.com>
> wrote:
> > > There's no way I can insist that everything is welded and smoothed?
> > > On Oct 4, 2:41 am, Morgan McGuire <morga...@gmail.com> wrote:
> > > > Looking at the source for ArticulatedModel, it looks like you could
> just
> > > > call computeBounds and updateVAR instead of updateAll and get the
> effect
> > > you
> > > > want. The normals won't be right, though--by definition, you can't
> > > update
> > > > the normals in place since you'd have to break some vertices to do it
> > > right.
> > > > -m
> > > > On Sat, Oct 3, 2009 at 3:07 PM, Andy H <andyhowl...@googlemail.com>
> > > wrote:
> > > > > Hi, thanks for the reply from whoever it was who gave it!
> > > > > I am still having problems though - the weld process, with these
> > > > > settings, splits up every vertex into multiple ones. What I want is
> > > > > for no vertices to be touched at all - my input list does not have
> 3
> > > > > unique vertices per face, many are shared.
> > > > > I could use a method that does not split any up. Looking at the
> > > > > process function, it seems I want normalSmoothingAngle to be used
> to
> > > > > determine where normals are smoothed, and then later on for
> vertices
> > > > > to be welded always whenever they are in the same location - I am
> not
> > > > > sure if this makes any sense, as you'd need to have planes store
> > > > > normals, not vertices, and possibly G3D works with vertex
> normals...
> > > > > I'm a bit out of my depth here! I tried setting the smoothing angle
> to
> > > > > 180 in the hope that all vertices in a certain position would be
> > > > > welded, but it didn't seem to work.
> > > > > Alternatively I could use a method that can work out which vertices
> in
> > > > > the new list are equivalent to a certain one in the old list. I
> > > > > thought about it but I don't understand how the vertex ordering
> (and
> > > > > repeating) is determined after processing.
> > > > > More info would be much appreciated.
> > > > > On Oct 1, 4:53 pm, corey taylor <corey.tay...@gmail.com> wrote:
> > > > > > This thread was lost.
> > > > > > The response from morgan was to set the normalsmoothingangle and
> > > vertex
> > > > > > weldradius to 0 in the articulatedmodel weld settings if you
> don't
> > > want
> > > > > the
> > > > > > vertices touched on load.
> > > > > > I wonder if anyone can give me some advice here. I'm trying to
> make
> > > an
> > > > > > editor that just allows users to move vertices around (for now at
> > > > > > least).
> > > > > > My specific problem is keeping track of vertices. I have a cube
> > > around
> > > > > > each model vertex, and am testing for collisions between the cube
> > > > > > faces and the mouse ray. The user drags the mouse around and the
> > > > > > program updates the vertex coordinates (don't know quite how
> yet),
> > > > > > then calls updateVAR on the relevant Part.
> > > > > > The file loading code runs updateAll, and then has to go through
> the
> > > > > > vertex array of each Part and do a proximity test with each of
> the
> > > > > > coordinates actually given to the articulated model, to work out
> > > which
> > > > > > of the vertices in the file corresponds with which in the
> articulated
> > > > > > model (and which vertices correspond to the small cubes). What
> seems
> > > > > > to have happened is that some vertices have been duplicated; I
> think
> > > > > > this has something to do with Meld but am not sure. With this
> > > > > > happening, I can't work out simply which vertices need to be
> moved
> > > > > > when.
> > > > > > So, can I stop the library from changing the vertex array when
> > > > > > updateAll is called? If not, is there some other way of working
> out
> > > > > > which vertices in the array need changing? The current method is
> > > > > > unsurprisingly extremely slow.
> > > > > > Thanks in advance.- Hide quoted text -
|
