United3dArtists Archive

stan · Post by **stan** » 07 May 2011, 14:07

yes Froo-bi-wan

great progress.

froo · Post by **froo** » 10 May 2011, 03:03

I had a couple bugs resolved.
The control surface is constructed one way: the outer loop scans over Y (i.e. V),
the inner loop scans over X (i.e. U).
The problem though, was the nurbs code was doing the opposite:
the outer loop scanned over X (i.e. U), while the inner loop scanned over Y (i.e. V);
reading the input control points, and generating the nurbs surface accordingly.

This is not a problem if we use a 'square' control surface: a 4 x 4 vertex set, or 5x5,
or 10 x 10, etc.

However, when we want to do some fancy dancin, and use a non-square control surface,
say, 4 x 6, then our ordering of loops matters. What happens is, we get the right number
of nurbs vertices, but the surface looks like a sheet of saran wrap (plastic wrap) that's all
wrinkled up. BTW I hate saran wrap. Pain in the ass to use. But I digress...

Once I resolved the ordering, I ran into similar problem, when I wanted a non-square output
surface. If I chose to create a 20 x 23 vertex surface, it was mangled, in a different fashion;
looked more like roadkill, to be honest (think 2 dimensional animals).

The problem here, was my calculation for indexing was wrong. Solved that too.

froo · Post by **froo** » 10 May 2011, 03:08

So, now with both of those bugs resolved, I can now make an interface
which will allow you to set the number of control points over U, and V,
as well as the number of nurbs vertices over U and V.

Note that currently, this plugin only generates a nurbs sheet. Next up,
will be more complex surfaces: nurbs sphere (for starters, then maybe a nurbs cube?
If it's needed; hm may be a little challenging), swept surfaces, ruled surfaces, surfaces of revolution,
skinned surfaces. These are a little ways off of course.

I still need to get the vertex/edge/triangle highlighting working correctly, but that should
be straightforward now, since I got the 'stuff' straightened out.

froo · Post by **froo** » 11 May 2011, 00:40

Well I got the vertex highlighting sorted out, sort of.
Ideally, I could either, turn it off completely for the nurbs surface (keep it on for the control surface only),
or, when I select a control vertex, all the nurbs vertices which will be affected are highlighted.
I tried both approaches but neither seemed to work too well.
So for now, when we select a control vertex, we see a rectangular patch of nurbs vertices highlighted.
While that is at least, a tidy presentation, I am concerned it will still be a bit of a distraction when you use it.

I think I will work on the interface next, because this highlight thing is kind of annoying me.

froo · Post by **froo** » 11 May 2011, 20:28

For now, the highlighting of nurbs surface vertices is disabled upon selection.
We'll see if you all like it that way or not.

I am working on the dialog right now. I can load the dialog from script.
Next up is passing the parameters for U/V control and surface vertex counts,
to the nurbs surface generator. Then comes the addition of the toolbar.

BTW..... could someone please make an icon for the toolbar button? I am not
so good at that. Since this is a nurbs Plane, maybe, it could be a bitmap of a plane,
with the text: NP (Nurbs Plane) on it? Something like that? Thanks!

Once that is done, it should be ready to go, for playing around with.

froo

clintonman · Post by **clintonman** » 12 May 2011, 02:17

Here's one you can try.

BNG · Post by **BNG** » 12 May 2011, 02:48

I look forward to testing it out when Froo get's it ready for release. To all of you who take the time and effort make these wonderful Truespace plugins I

you all. BNG.

froo · Post by **froo** » 12 May 2011, 03:42

Thanks BNG.
Clinton, that is Bad Ass man! Thanks!
I'll get and use that.

froo · Post by **froo** » 12 May 2011, 20:50

Ok.
So, with a 400 x 400 vertex surface, we have 160,000 vertices.
Tomas indicates each vertex has some extra stuff attached to it
when pushed to the GPU. Each vertex ends up being 96 bytes.
So, that amounts to: 15.36 MB that are being pushed to the GPU
every time an edit occurs. An edit can be just moving a single control
point. What ends up happening is, the GetMesh function that I use,
which performs all the math, gets called repeatedly, since we are
basically receiving mouse events indicating the edit.

So, imagine pushing the entire mesh, 15.36 MB worth, to the GPU
many times per second. This will really slow tS down.
The answer, is the timestamp blocks/streams. These streams contain
only those triangle blocks which have changed. I only process those,
instead of the entire mesh. This should speed things up and allow much
denser meshes.

froo · Post by **froo** » 14 May 2011, 15:57

Ok. So, I have a question.
One feature of nurbs tools is the ability to add a row, or column, of control vertices,
in order to add detail.

When that is done, are additional nurbs surface vertices also created? Or,
is the 'region of control' of the surrounding control vertices modified? Or both?

By modified, I mean this:

originally, a control vertex affects U, V region: U: {0.2, 0.4}; V: {0.2,0.4}
after adding a control row, that same vertex now affects
U,V region: U: {0.2, 0.3}; V: {0.2, 0.4}

stan · Post by **stan** » 14 May 2011, 19:46

shouldn't any newly added row have the same vertice count as the others for both. Then it would be the same as your primitive creation values too.

froo · Post by **froo** » 20 May 2011, 21:04

Ok I believe I have a good foothold on understanding the IRdTriangleTimestampStream.

If we are in *** SORTED *** mode
(which we are, though for some plugins this may not be possible; need to ask Tomas why):

The variable: dwNumActiveTriangles tells us the exact indices of changed triangles in
the *** SORTED *** triangle stream. The indices are: 0 ... dwNumActiveTriangles-1.

So if dwNumActiveTriangles = 24, then we know that output triangle indices 0 - 23
are the ONLY triangles which require updating. The rest of the mesh can be left alone.

If we are not in Sorted mode,
dwNumActiveTriangles = -1 (0xFFFFFFFF), and we need to refer to the timestamps
in the dwTimeStamps[] array, of timestamp blocks.

Another way of putting this is, if we cannot guarantee that the first dwNumActiveTriangles will be
the 'Active' triangles affected by an edit, then we need to set dwNumActiveTriangles to -1, and use
the timestamp values in the dwTimeStamps[] array. How?

We preserve the base timestamp from the previous edit (the last time we were in the function
where we access the variable: dwBaseTimestamp. Once we enter the function again, we compare
the 'old' dwBaseTimestamp (stored on a connector most likely) to every (?) triangle block timestamp
in the dwTimestamps[8192] array. If the timestamp for a triangle block is > the 'old' timestamp,
then the triangles contained in that triangle block are affected by this current edit, and we
therefore need to add them to the 'list' of triangle indexes to be updated in the output mesh.

So. How do we calculate the triangle indexes in this case?

We know the triangles per triangle block. This is contained in the variable:

dwTrianglesPerBlock

And we know the block index that contains the affected triangles (this block's timestamp
is > than the 'old' timestamp).

So the equations would be:

ActiveTriangleStart_ForThisBlock = dwTrianglesPerBlock * block_Index;

ActiveTriangleEnd_ForThisBlock = dwTrianglesPerBlock * block_Index + (dwTrianglesPerBlock - 1);

The one thing I am not sure about is this:

Are all the blocks in the array initialized to a valid
timestamp value, when we need to use the timestamps?

Or, are they mostly uninitialized, as in the case where we can make use of the dwNumActiveTriangles
variable?

I do not think I need to be concerned with using the timestamps for this plugin, so I will not
worry about them right now. Maybe for another plugin though.

So. How do we process only those triangles, and not the entire output mesh?

The mesh is already stored on the output connector.
So, we just:

acquire that mesh

Lock the triangle stream

modify only those active triangles according to the nurbs equations

Unlock the triangle stream

Push the mesh onto the connector

froo · Post by **froo** » 24 May 2011, 20:03

I ran a quick test.

Control mesh = 18 x 18 triangles = 324 triangles
Output mesh = 400 x 400 = 160,000 triangles

Number of output triangles generated per control quad (2 control triangles): 18

Select a single control vertex - numActiveTriangles (input, max) = 24

Number of INPUT triangles to process: 24 / 324 (numActiveTriangles / ControlMeshTriangles) = 0.074074
This is: 7.407% of the total input triangles

So, as a rough calculation, we can expect to update less than 10% of the output control mesh when we edit a single control vertex. That is, 90% less throughput to the GPU. A significant savings. Of course, this will change if we edit more than one control vertex. But, 'change' does not necessarily mean, 'get worse'. It looks like it fluctuates.

We'll see what happens soon!

froo · Post by **froo** » 25 May 2011, 22:17

Creating some code which I think will properly scrub through
the selection streams and give me Only the vertices which I
need to process during edit mode.

Long story short, I will be creating a list of vertices to process.
But, since this list is derived from the list of 'active triangles', I will
end up with the same vertex listed more than once. I do not
want to run a vertex through all that math more than once.
I believe there is a C++ vector<> member function, called 'Unique'
or something, that I can use to take a vector of vertex indices,
and create another vector containing only one copy of each vertex index.

Like this:

std::vector int Orig is: { 0, 0, 0, 0, 1, 5, 5, 5, 5, 5, 8, 19, 19, 19, 21, 21, 21, 34, 34, 34, 56}
std::vector int New is: {0, 1, 5, 8, 19, 21, 34, 56}

Then I have a list of those vertices which need processing (the New vector, above).

There is probably a faster way to do this, but at least this will prove whether the concept will
work or not.

froo · Post by **froo** » 26 May 2011, 23:55

Well I got that part working
but there are still some things I don't understand.

I need to 'save the previous version' of the mesh data (all its streams),
Lock that previous version, and update only those sections that have changed,
then put this whole dataobject on the output.

Just a little confused about this. Anyway.

froo · Post by **froo** » 03 Jun 2011, 22:15

Got the 'keep the last version of the mesh' issue resolved.
So now when I enter edit mode, I am using the 'kept' version
of the mesh, and am displaying the control surface.

froo · Post by **froo** » 08 Jun 2011, 03:23

I am thinking, I need to split up the code, so only the 'backup copy / old version' of the
mesh uses the selection and visualization streams, and the 'regular / no edit mode' mesh
does not use those streams. I am working on that now, but sort of hacking it at the
moment, just to see how I want it to 'look', to see how it should be organized.
Probably not the best way to do it. I think I should put it down for a couple days
and work on some animation or something.

froo · Post by **froo** » 09 Jun 2011, 03:57

Split out the code.
tS hangs still when I am working in edit mode.
But the code is cleaner and the logic is easier to follow.
So it should be easier to see what's going wrong.

BTW was watching some youtube videos of The People's Court.
Is it just me, or is the judge Marilyn Milian just totally Knockout HOT?!

froo · Post by **froo** » 09 Jun 2011, 16:42

Update:

I thought the plugin was causing tS to hang last night.
This morning it is not. Interesting.
When I enter edit mode, and push and pull verts around,
I see no updates. But when I exit edit mode, I see the
changes to the surface.
This is progress. I am getting closer.

froo · Post by **froo** » 10 Jun 2011, 05:44

Well I got that problem partially solved. Though, it looks like, sometimes the wrong verts are shown to update.
But when I exit edit mode, the mesh is correctly updated. I'll get that fixed.
The problem was that I was using the wrong pointer variable to access the input vertex streams.
I have a class member variable: m_pInVertices, that points to the input control vertex stream.
In the edit function, I declare a different pointer: pInVertices, which is used for indexing through the
input vertices. The trouble was, I was still using m_pInVertices for the nurbs calculations. Since that pointer was not getting incrementing, I was basically not getting anything useful out of the calculations.
Anyway. It's partly solved.

froo · Post by **froo** » 10 Jun 2011, 06:20

here is the source code thus far. Still in work, but it's at a point where it can be
analyzed and reused, I think. The edit-optimization isn't quite there yet.

Feel free to ask questions.

Steinie · Post by **Steinie** » 10 Jun 2011, 11:34

froo wrote: Feel free to ask questions.

OK, What is the meaning of Life?...

Fantastic work Froo! Thanks for sharing.

froo · Post by **froo** » 10 Jun 2011, 16:20

haha thanks Steinie !

I have been wanting to upload the code for some time, but felt I needed to get it to a
certain point before doing that. The optimization for edit mode is not yet working,
but almost there. Aside from that, there is a lot of reusable code there for other editing
type plugins. However, until the edit optimization is complete, editing large vertex count
meshes will be slow.

I should probably make a thread exclusively for this source code or, better yet, ask Clinton
if I could put it on his website (listed as Beta). And put it on the truespaceplugins.com site
as well. And maybe trueBlue's, and Steinie's, and...

clintonman · Post by **clintonman** » 11 Jun 2011, 20:53

froo wrote:haha thanks Steinie !

I have been wanting to upload the code for some time, but felt I needed to get it to a
certain point before doing that. The optimization for edit mode is not yet working,
but almost there. Aside from that, there is a lot of reusable code there for other editing
type plugins. However, until the edit optimization is complete, editing large vertex count
meshes will be slow.

I should probably make a thread exclusively for this source code or, better yet, ask Clinton
if I could put it on his website (listed as Beta). And put it on the truespaceplugins.com site
as well. And maybe trueBlue's, and Steinie's, and...

Sure, we can put it up on my site. Just let me know what you have in mind and it doesn't have to be limited to one section or web page either.

froo · Post by **froo** » 22 Jun 2011, 23:12

I think I will shelf this for awhile.
In all honesty I think I am just tired of screwing with it.
There are so many nurbs tools, and others out there, so why
bother trying to make another one? I could probably spend an
entire lifetime trying to get this to work, when I could just get
some freeware somewhere else to make organic shapes. In fact,
like, sculptris. Super fast, etc. Yeah I know sculptris does may not
have trimming and stuff but the mesh can be imported somewhere else
for that. Heh. Anyway. I may pick this back up; not sure. I don't think
there's enough need for the tool. Plus, I really need to learn Messiah,
and I can still use what I have, the source code to date, as part of
my portfolio. Yes it is not complete (at least, using the 'optimization' streams),
but so what? Good enough.
I'm not being negative, just tired of diddling with this. And honestly, I don't think
this is really in demand.

I really want to actually make some models, and animations
anyway. And texturing (I don't know ANything about that, and UV mapping).

I think I will try making some other fun things though, like lightning. That may be kinda neat.
Just tired of trying to figure out why some of this is so slow. I guess I'm just not in the mood
for it.

stan · Post by **stan** » 23 Jun 2011, 01:19

I understand how you feel..the standalone has been a huge undertaking and I had to put it down afew times.

It is summer after all, sounds like you need a double dose of grand marnier cookies with a few shooter to boot..

froo · Post by **froo** » 23 Jun 2011, 03:43

haha yeah thanks stan.
Well, I'm just tired of looking at the code, realizing how much more work is required.
See, it looks like it works, but the way I coded it, was as I thought it out. Which means,
some of the code is very simplistic, and pretty much, the worst way I could possibly
write it. Extremely slow. I know there is a faster way to do it.
I get an input triangle which is 'active'. Then, I loop through the whole mesh (all triangles)
to see if each of those triangles matches up with that particular active input triangle.
If so, I add the triangle to the list. Then I repeat that, for each output triangle. See
how that can go downhill really fast? It is easy to read, and understand what I am doing,
but it is not the right way to do it. And I just don't feel like 'thinking' about it. You're right.
I really do need a break. And animations too!

froo · Post by **froo** » 24 Jun 2011, 03:16

REBOOTING................................
...............................................
...............................................
...............................................

froo · Post by **froo** » 24 Jun 2011, 03:54

Ok; back. I've cooled off I suppose.
There is something seriously wrong with this approach.
That's why it makes no sense to do it the way I am doing.
I do not need to use the timestamp stream. Here's why.

I select two triangles ( a quad ). So, two entries in the selection
stream have their selection flag set to 1. That's good.

But, the dwNumActiveTriangles is 18. That's bad. Why?
Because there's 18 triangles in the control surface. That means,
the entire surface has to be processed. That's stupid.

That should simplify things a bit. If I know the selected triangles,
then I know the selected vertices. If I select two triangles, then I
have to process a maximum of 6 vertices. Not the whole damn thing.
Again, that's stupid.

froo · Post by **froo** » 24 Jun 2011, 04:09

marked improvement already.

clintonman · Post by **clintonman** » 24 Jun 2011, 04:36

Yep, sometimes you have to walk away and come back with fresh eyes when doing these things.

froo · Post by **froo** » 24 Jun 2011, 05:11

Yeah, that's true clinton.
Thing is, the documentation says, it's important to use that stream, to determine the exact number of triangles being updated during an edit. If we don't use it, it will cause a slowdown. etc. etc.
That may work for some cases, but not for this one. For some reason, this fact totally slipped past me for awhile:
I select 2 triangles, and the active triangle count is 18 (i.e. the whole control surface). That doesn't sound like an 'optimization-during-editing' to me!
It may be, that when working with much larger meshes, its use may be valuable. But, it still seems
more sensible to just check the selection state of triangles. At least, for this plugin. For other editing plugins, its use may be more valuable.

I may already be doing this; I recall thinking it through in this fashion while writing the code - order the output mesh according to the input mesh. Meaning, generate all output triangles for triangle 0, and index them as such:

in: 0

out: 0 1 2 3 4 5 6 7 8

in: 1

out:
9 10 11 12 13 14 15 16 17

....

then, when I know which input triangles are selected, I should be able to just grab 'ranges' of triangles for updating, and load them into a vector. This, as opposed to looping through the whole output mesh.
If 1 input triangle generates 25 output triangles, and I select in triangles 5 and 12, then I should be able to grab 50 triangles without a loop.

froo · Post by **froo** » 25 Jun 2011, 15:54

Well, I shouldn't give up on this and here's why.
I can always improve my problem solving skills,
especially as applied to my career as a software engineer.
The current issue is an optimization problem during editing.
At present, the output triangle stream is organized row by row.
This causes an issue during edit mode: I have to loop through all
triangles, repeatedly, as I check to see if each triangle
matches a selected input triangle. That takes a VERY long time.
Rather than doing this, the solution is this:
On surface creation, fill the output triangle stream according
to original triangle, like this (already posted above I guess):

original triangle 0: generate output triangles
original triangle 1: generate output triangles
etc.

Then I don't need to loop through every triangle, repeatedly,
during edit mode.

So even if it's not used at least I strengthen my position as a software engineer.

froo · Post by **froo** » 21 Jul 2011, 03:20

Taking another go at this.

So here's the deal.

I have to rework the order in which the surface triangles are written to the data stream.
The end goal is to write all surface triangles generated by control triangle 0 first, followed
by triangles generated by control triangle 1, etc.

Tomas pointed out that each control quad (2 triangles: 0 and 1) generates a set of surface triangles.
So, that is what I am now trying to do. I have 2 vectors; one for each control triangle in the quad.
I know how many surface triangles I will generate for each control quad. Once I reach that value,
both vectors are filled; at that point, I load the triangles from vector 0 (for control triangle 0) into the triangle stream, followed by the triangles from vector 1 (for control triangle 1).

more...

froo · Post by **froo** » 21 Jul 2011, 03:26

I know that, for control triangle zero, the first generated surface triangle will always be bottom-heavy (2 verts on the bottom, one vert on the top). Likewise, for control triangle one, the first surface triangle will always be top-heavy (2 verts on top, one on bottom). I have 2 boolean variables; they keep track of the orientation of the current triangle to generate (is it bottom-heavy? or top-heavy?)

Note that, this explanation is applicable to when the surface is first generated; i.e. we have a nice, flat, square surface.

So, as I am stepping through the triangle count, I determine whether the surface triangle is generated by control triangle 0, or 1. As I do this, I toggle the boolean variable, since I know that the next triangle I draw will have its orientation (bottom-heavy, or top-heavy) the opposite of the current triangle.

more...

froo · Post by **froo** » 21 Jul 2011, 03:27

bottom heavy:

Code: Select all

*
 \
  \
   \
     \
       \
*____*

top heavy:

Code: Select all

*_____*
        /
      /
     /
    /
   /
  /
*

froo · Post by **froo** » 21 Jul 2011, 03:33

Ok so I need to upload a drawing. My ascii art skills obviously suck.
So anyway.

Each quad generates a specific number of triangles in a row.
When I reach that count, I reset the boolean flags, since I know
I will be creating a 'first' bottom-heavy, and a 'first' top-heavy
triangle at some point.

This will probably make more sense in a drawing/sketch.

When the surface is constructed, I will have this:

Surface triangles from ctrl tri 0
Surface triangles from ctrl tri 1
Surface triangles from ctrl tri 2
Surface triangles from ctrl tri 3
etc.

froo · Post by **froo** » 21 Jul 2011, 03:37

So. Why is this important?

Because, when we enter edit mode, and we select, say, control triangles
4 and 9, then I can quickly determine which sections of the surface triangle
stream I need to manipulate. How? By calculating the offsets into the triangle stream.

In doing so, I should be able to get a large improvement in speed when editing large meshes.

Ok; so, I know that normally when playing with nurbs editing we edit the control Vertices,
not triangles. But, with this plugin, you can do both. Vertices, triangles, sections, etc.
The same logic will apply. But I am applying it to triangles for now, to get it to work.

froo · Post by **froo** » 25 Jul 2011, 21:07

Ok,
I got the math sorted out now.
It's really just a bunch of shifting/jumping:
shift to the next control quad in the row, jump
to the next row of control quads.
Yeah like that makes sense.
Hey now, it's a lot simpler than all the mathema-voodoo chatter
I could throw out there!

Long story short, the triangles are ordered differently, to make
editing run faster. I have them stored in vectors.
Next up is, loading the data from the vectors into the triangle streams.
I think I can do a simple memcpy; we'll see if that's allowed.

froo · Post by **froo** » 26 Jul 2011, 23:19

so, now I am wondering, if I even need to check the original triangle index.
Why?
Because, if a vertex of control triangle 0 is selected, and nothing else,
then I know, that the only triangles affected are those generated by
control triangle 0. I don't need to check the original element index.
But, I do need to disable that 'optimization', where the stream is sorted
during edit mode.

froo · Post by **froo** » 27 Jul 2011, 15:13

Not only that, but do I really care about triangles at all?
Stan mentioned some time back that we manipulate vertices,
not triangles.
If I don't use a lot of the triangle-processing stuff, no problem.
There are a few good ideas in there that are needed for other
editing type tools. Handling selected triangles, for example,
would be required for a less-complex editing tool. We'll see.

froo · Post by **froo** » 28 Jul 2011, 01:07

Did some testing.
Looks like the concept will work; it is much faster than the old approach.
Still dealing with triangles (not vertices) at the moment.
But I've proven to myself that the code I was using is
ghastly slow.

froo · Post by **froo** » 09 Aug 2011, 14:46

I figured out why tS crashes and the surface disappears when I enter point edit mode,
instead of 'triangle edit' mode. Because the triangle selection stream is NULL. That makes
sense, because we are selecting vertices, not triangles. In contrast, in triangle selection
mode / triangle edit mode, when we select a triangle, we are also selecting 3 vertices.

So. I am working on some code to efficiently process the selected vertices, and the
affected surface vertices. Here's the challenge:

if I select more than one control vertex, then a surface vertex will end up getting listed
more than once. We don't want that; we do not want to process a surface vertex two
or more times. So, I am looking to see if I can find a fast algorithm that will allow insertion
of a vertex only once.

stan · Post by **stan** » 09 Aug 2011, 15:11

cool..once you get vertices working will you get rows of verts going too..?

froo · Post by **froo** » 09 Aug 2011, 17:47

How do you mean, stan?
Do you mean selecting an entire row of control vertices all at once?
Or, do you mean, adding new rows of vertices?
I think you are referring to adding rows of vertices. Yes, I would like
to get that going.
I also should archive this version containing the triangle stuff, even though
it is not working the way I would like. Triangles are better for another plugin
anyway.

froo · Post by **froo** » 10 Aug 2011, 03:19

Ok; got the 'vertex selection' stuff working again.
The 'triangle selection' stuff is commented out.
During edits, the surface updates correctly, instead of just
the 'triangle chunks' getting updated which looked horrid.

froo · Post by **froo** » 11 Aug 2011, 15:41

I am going back to a previous version to incorporate the vertex selection stuff.
With the current version I get messed up triangle indexes. Originally I was trying
to arrange the surface triangles by control quad: create all the triangles for the
1st control quad, then move on to the next. While that is possible to do, it is not
necessary for this plugin and the math is a little hard to understand.
I checked the last version I created, which does not use that funky math.
Worked ok. So I need to get my vertex stuff in there.

froo · Post by **froo** » 12 Aug 2011, 04:39

Ok looks like that's working now.
Here is another alpha version.
There is a bug; if you restart trueSpace, then try to continue editing the nurbs surface,
tS will crash. I need to look at that.

This alpha release should be much faster when working with larger surfaces.
When I tried a 25 x 25 control surface, and a 400 x 400 nurbs surface, tS seemed
to be 'spinning'. It did not finish generating the surface before I killed the process.
So I'll take a look at that.

It appears more responsive than when using triangles and triangle sorting, etc.

Let me know what you think.

Thanks!

Froo

froo · Post by **froo** » 08 Jan 2012, 17:58

Maybe I can take another look at this.
Since I don't need triangles at all I can strip that code out and focus only on vertices.
The triangle code can be useful for other plugins but I don't think it is really working
correctly. I never did completely understand how it works but that's what I get for
not sketching it out on paper BEFORE coding it. Anyway.

Let's see... where did I leave off... it was with a vertex block optimization thing.
I tried using it but it didn't seem to work the way the standard tS stuff works.
I created a basic cube with about 100,000 vertices and when I entered it mode to select
a chunk of vertices, it worked fast. When I did the same with my code it was much slower.
So, I'll take a look at that.

stan · Post by **stan** » 09 Jan 2012, 21:34

Good to see you get back to this..

froo · Post by **froo** » 10 Jan 2012, 15:09

Thanks stan. Looking forward to making some sense out of it.

Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

The Motivation For Use of the TriangleTimestamps

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread

Re: Nurbs Workspace Plugin Thread