Also it is unclear if you are doing "column" polylines, or "column" through point curves.
Or just joining the ends of the "row" polylines?

I would think that there should be multiple columns of curves, about the same as the row curves.

Are you trying to network ribbons, or a grid?

A reduced size demo "3dm" would be nice to see?

- Brian

I think Network works on a grid, "quad-ish", like a very wavy screen door screen.
- B

You would need to do a second data set in column format?

Thanks for the suggestions Brian. I'll try that.
Maybe if I make a surface for each of the smaller units and remove the polylines, I can then join the surfaces up with a smaller hit on memory/processor.

Maybe Loft?
Networks seems better way?
- B

Let P be a matrix of points. Just the raw point.z values need be stored. ( Pt.z ).
The row numbers are the x coordinates (possibly scaled a bit).
(Or store all the raw point data, Pt, with Pt containing (Pt.x, Pt.y, Pt.z))
The column numbers are the y coordinates (possibly scaled a bit).
P is a javascript array of arrays, and is zero indexed.
P[i][j] = P[row][col] is of dimension 2,400 by 2,400 = 5,760,000 z values.
The entries of P can be accessed by row, or by column, to create the curves.

If there is too much data, smaller chunks of P could be accessed, either n rows, with all columns,
or vice versa, or rectangular subsets of the matrix could be accesed.

Well, a few thoughts anyway.

- Brian

I wonder if the surface edges/ surface results of network chunks join up the same as the surface result of a complete network?
And what are the geometry data limits of MoI4?

Mmmm, good point Brian. Will have to experiment to see if the chunks will join along their edges.

I've created a much reduced data set with just 20 curves for testing (attached).
I also include 2 images to show the resulting model before and after the surface has been applied. All works very well, although the network operation takes time even with this many curves.

And here is the modified script I used to load the multiple curves. It was a quick job and I've only tested it with Polylines!

Here is the 3dm file for the model before I remove the polylines from the surface.

And here is the final surface with a basic road aligned above it, ready for projection.

Trouble is, I can't get it to project onto the surface for some reason. I've used projection before without issue.

Any ideas please? Thanks!

Seems your object is out scale of the Origin !
Default Grid is 300 * 300
Your object is 123 600 * 2 000

Sorry, don't know what that means! I have used the longitude for the Y axis so yes, the values are large but I don't think that makes much difference to the result.

All the axis are scaled correctly in cm.

Just tried the same projection operation with MOI 3.0 and it worked fine. Must be an issue with the beta version.

You right!

After much setup, Flow was used to place the road on the terrain.
The road width was increased by 1.03 unit.
The road length was increased from 120353.40units (inches) to 120437.02units (unwrapped length, one side),
or reduced to 120289353.40 units per MoI reading.

The entrance and exit ramps of the terrain probably throw measurements off.

The two long terrain curves (copied edges) were Unwrap(ed), and the start and end widths as curves, were oriented line to line with the long
unwrapped curves. Do Planar. The center points of the start and end widths were found, and vertical line segments to unwrapped surface
established two points for orient line to line, to move the unwrap surface. Then do flow.

Projection did not seem to work for me, or was not done right. MoI4.

- Brian

Projection worked fine in MoI3. The file did take minute or so to load...
The projection separates to 441 curves...

Thanks for your efforts Brian, haven't tried flow before - must give it a go but it does sound complicated!

The new version of MOI definitely seems to load this model faster.

< it does sound complicated!

Not really! ;)

Hi Sutts, it isn't good in general to have your models at a scale like that where the coordinate values are in the hundreds of thousands. The way floating point math works is that the precision of calculations is reduced when numeric values are far away from the origin like that.

One of the differences between 32-bit and 64-bit code is that floating point operations in 32-bit code using the x87 floating point instructions would actually have an extended 80 bit register value so some operations could be carried out at a higher precision before being stored back into memory. That has been lost in the transition to 64-bit, the 64-bit instruction set does not have that kind of extended precision.

So a side effect of that is that it is possible for cases that are difficult to calculate numerically like you have set up here that the 32-bit version could behave better than the 64-bit version.

However, what you're trying to do here is really not a great fit for NURBS in general. NURBS are not well suited for terrain, polygons are a better fit for this.

- Michael

That looks pretty impressive thanks. Will definitely look into that feature.

Thanks Michael, that makes perfect sense. Pure laziness on my part for not scaling those values back. I'll fix that and try projecting again.
The end goal of this particular exercise is not the terrain itself. I'm modelling an airfield layout with MOI and need the terrain to project the 2D model onto so that the model follows the terrain when I place it on the landscape in the Unreal 4 engine. I'd much prefer to work with MOI but if I can't get it to handle these massive chunks of data, can you suggest an affordable polygon modeler that might handle it please?

I'll continue to use MOI for everything else as it's absolutely superb. You must have put a lot of time and thought into the interface as it's amazingly intuitive. The projected snap points are so useful and all the constructs/transforms are child's play compared to the overly complicated features in Solidworks. Top marks!