PDA

View Full Version : instant teapot



irt
08-07-2012, 03:37 AM
Is there an instant teapot model. Can't find it in the create menu or add it from "edit menu" .
Thanks

BeeVee
08-07-2012, 09:09 AM
It depends what version of LightWave you are using. The Utah teapot was a preset for a long time, but has been removed from Modeler since v9, I think.

B

irt
08-07-2012, 03:51 PM
Thanks, glad to know I hadn't imagined it.

iain_r
08-08-2012, 05:26 AM
Hi, 32 and 64 bit versions of the Utah teapot. Works with 9.6, haven't tried with any other version.

Regards

Iain.

BeeVee
08-08-2012, 06:23 AM
I can confirm it works in the very latest LightWave too. :)

B

irt
08-08-2012, 07:28 PM
Thanks Iain it's working :thumbsup:

daforum
08-09-2012, 08:08 AM
Hi, 32 and 64 bit versions of the Utah teapot. Works with 9.6, haven't tried with any other version.

Regards

Iain.

Is there a version available for Mac (either as a .plugin, or .ls)??

iain_r
08-09-2012, 10:50 AM
Hi, I can take the code that I used for the plugins and write an lscript file. I may have one on another machine already. I'll post the file when I get a chance. I don't have a Mac to make a compiled plugin.

Regards

Iain.

jeric_synergy
08-09-2012, 11:58 AM
Do these plugins just store the data? I mean, except for the exercise, it's just clipart.

daforum
08-10-2012, 02:27 AM
Hi, I can take the code that I used for the plugins and write an lscript file. I may have one on another machine already. I'll post the file when I get a chance. I don't have a Mac to make a compiled plugin.

Regards

Iain.

Cool! Thanks iain_r. An lscript would be great.

iain_r
08-11-2012, 06:31 AM
Finally managed to get the lscript file created. Used the values from the SDK version that comes with 11. Should work on any version, obviously a lot slower than a compiled plugin while is does all the loops. Added a progress monitor.

I checked this in 9.6 and 11.

Regards

Iain.

iain_r
08-11-2012, 06:33 AM
Jeric, what do you mean by "Do these plugins just store the data? I mean, except for the exercise, it's just clipart.". The plugins hold the point and polygon info, I don't know what clipart has to do with this.

Regards
Iain.

jeric_synergy
08-11-2012, 09:29 AM
Store the data, versus create the teapot procedurally.

If the teapot were created procedurally it would be easy to, say, add more divisions. But if it's a straight collection of points that are joined together poly by poly, adding more divisions would be virtually impossible.

Still worthwhile for the programming experience. A collection of points is really just a different storage media for clipart, since it can't be altered by the user. Loading the (clipart) object is tantamount to running the plugin, and vice versa.

daforum
08-11-2012, 03:00 PM
Finally managed to get the lscript file created. Used the values from the SDK version that comes with 11. Should work on any version, obviously a lot slower than a compiled plugin while is does all the loops. Added a progress monitor.

I checked this in 9.6 and 11.

Regards

Iain.

Thanks iain_r, works here too.
It is a little slow and I got a beachball as the progress bar finished, but it made the teapot.

Thanks for doing this :thumbsup:

jeric_synergy
08-15-2012, 12:30 PM
I bet there's plenty of other objects that would be nice to have one-click solutions for. For instance, just now I made a circle, then realized I needed a 'gridded circle'. That's a handy mesh to have access to quickly, and more generally useful than a teapot, I reckon. (And offhand, simply making one manually seems a bit laborious, with a signficant # of points.

If there were a methodology/script that you could submit a mesh to, and it would spit out a script or plugin that one could add to the menus, users could accumulate their favorite 'primitives'.

Of course, procedurals would be 'better', BUT a lot of these objects just need to be scaled up/down for a wide range of uses.

How were the teapot data points entered into the plugin?

++
Plugins like this could also make certain workflow practices automatic: I often make a 'Perimeter' point set-- a plugin could include that action. Or the inverse, all points except the perimeter-- whatever works for you.

iain_r
08-15-2012, 02:08 PM
Jeric, the points and polygon information was hard coded in the file. The function to create the teapot just looped through the arrays and added points and polygons to modeler. The original data that I used to create the c plugins came from the datasets for the Utah teapot that I found online. The lscript file I used the data supplied with the sdk for 11.

You need to cater for tris and quads and possibly ngons so you would need to test for the number of points to issue the correct number of addpoints before the addpolygon command.

Regards
Iain

jeric_synergy
08-15-2012, 02:51 PM
No worries: I figure the scanner portion would just duplicate each poly, brute force.

The reconstruction side could perform a Merge Points at the end, and WALLAGH! (Or, that could be an option.)

Conceptually dead simple. I bet it would be slow too. But faster than doing it oneself.
It sounds like just the scanner needs to be written.

Philbert
08-15-2012, 06:15 PM
Now if only there a was a plugin that could give me a barrel with an eagle inside.

jeric_synergy
08-15-2012, 06:18 PM
Now if only there a was a plugin that could give me a barrel with an eagle inside.
Those were the days. :beerchug:

Seriously, wouldn't it be nice to have a little "Platonics" generator for your own personal platonics? (I realize I'm abusing the word....)

BTW, what ever happened to the "Thorntagon"? I couldn't find any mention of it online.

iain_r
08-17-2012, 07:20 AM
Ok Jeric,

This just a quick script to create an lscript from a model. It needs to be tris or quads or both, no 1, 2 on ngon polys or subd. It saves the file to whatever directory you choose. You need to give the file a .ls extension. It takes the name of the file and saves it in the lscript so that you can add it to the menus, it also handles spaces in names.

I need to think how to cope with non tris and quads, but I'm heading off on holiday shortly so it will need to wait.

Regards

Iain.

jeric_synergy
08-17-2012, 12:27 PM
WOW, thanks iain_r! I think this will be a fun addition to our armamentarium.

(I can't BLEEVE spell check doesn't have "armamentarium" -- I use that word All The Time!)

Discussion:
w/o reverse engineering your script: why are ngons an issue? If you are just sequentially selecting polys and replicating their points, don't you get ngons "for free"?

Thanks man, very cool. Now users can create their own favorite shape in one click! No more making a sphere and merging the pole polys (which are tris) to get all quads! Nurnies at our fingertips!

stiff paper
08-17-2012, 03:07 PM
Arsenal.

jeric_synergy
08-17-2012, 04:43 PM
that's no fun.

iain_r
08-18-2012, 09:05 AM
Updated script which should now handle polygons with any number of points. I tested this with the gemstone which has 3, 4, and 8 point polys. Worked okay.

Use at your own discretion.

Regards

Iain.

jeric_synergy
08-18-2012, 05:17 PM
Fabulous, Iain. Thanks.

EDIT: sadly, managed to crash it on my second use. (Was trying to see if the script would retain Surfaces.) Crashed Modeler, and now Modeler won't launch!!! More in a bit.

Meanwhile, treat with extreme caution....

jeric_synergy
08-18-2012, 11:38 PM
Iain_r's "CreateLscript.ls", version2, unfortunately appears to be capable of creating poison lscripts that will prevent LWM and Layout from launching, if Autoscan is on.

ATTACHED find an example of such a poison script. I suspect that attempting to "Primitivize" larger objects with higher point/poly counts than the script is able to accommodate creats a poison lscript, as the originator script generates safe lscripts from simpler objects.

Also attached find a safe, non-crashing lscript generated by ian_r's cool lscript.

If "CreateLscript.ls" can be made safe, either by enlarging array sizes or simply inserting point/poly count checks, I think it will be real fun to have one's own, personal primitives. :thumbsup:

WARNING: to prevent Modeler from failing to launch, delete the "TestObject2.ls" from your plugin folder, or turn off Autoscan.

TestObject2.ls is the poison script.
TestObject.ls is the safe script.

jeric_synergy
08-20-2012, 11:46 PM
I'm no programmer, but taking a glance at the poison generated *.LS, I noticed this bit near the end of the vertice list: that doesn't look right.....



verts[2362] = <1.24458,1.1982,0.3>;
verts[2363] = <1.24135,1.24068,0.3>;
verts[2364] = <1.24111,1.257,0.3>;
verts[2365] = <-1.#IND,-1.#IND,-1.#IND>;
verts[2366] = <-1.#IND,-1.#IND,-1.#IND>;
verts[2367] = <-1.#IND,-1.#IND,-1.#IND>;
verts[2368] = <-1.#IND,-1.#IND,-1.#IND>;

What could be going on here? Is 2365 anywhere near a natural limit of LScript arrays?

iain_r
08-26-2012, 11:58 AM
Jeric, please stop using "poison" to describe the generated lscript.

I've just run a test using the Draggie model and generated a script with details for 8601 vertices and 8296 polygons and no corruptions are recorded in the file. It's not a limit of lscript arrays as the create file is parsing through the point and polygon information in modeler and it is being written directly to the file.

The -1.#IND would suggest that the value returned was not a number. Have you tried the script on another model with multple points in the polygons? What does modeler report in the statistics or point information for those points, i.e what values does it display for verts 2365 through to 2368.

Regards, Iain.

jeric_synergy
08-26-2012, 12:17 PM
Jeric, please stop using "poison" to describe the generated lscript.
That's my generic term for "items that load and kill the application", which can be plugins, scripts (apparently), meshes and images.

It's convenient and descriptive, and discriminates between the perfectly functional files CreateLscript has generated with a minimum of typing. (And 'bad' is boring and vague.)


The -1.#IND would suggest that the value returned was not a number. Have you tried the script on another model with multple points in the polygons? What does modeler report in the statistics or point information for those points, i.e what values does it display for verts 2365 through to 2368.

Regards, Iain.
I tried it on two different objects that generated, ahem, 'bad' files that prevented the applications from launching. I also generated several perfectly functional smaller items. The bad meshes were extruded 'text objects'.

I'm away from that machine, but when I get to it I'll make a couple more. Didn't I upload them above?? EDIT: apparently not.

jeric_synergy
08-26-2012, 06:33 PM
At home, generated some samples for Iaian_r:


attached is the LWO from which the @^@ 'bad' file gets generated.

Next attached is the generated file that causes LWM to crash.


I didn't check ('cuz it's incredibly aggravating), but before, having AutoScan (plugins) ON would prevent LWM and LW from launching, which I find very surprising, since it implies that they both run the lscripts to some degree, on scanning. WUWT?

Immediately before generating this crashing script I used CreateLscript.ls to generate a file from a simpler mesh, and that one worked fine. (Attachment #3)

Looking at the bad file's code, I see nothing obvious in the vert or poly list like a previous generated script had.

So, now you have a culprit to autopsy!
+++
EDIT: btw Iain, I'm running 64bit here.

iain_r
08-27-2012, 04:32 AM
Ok, so I used the lwo file to create an lscript. I would appear to be a limit in lscript with regard to the size of bytes used by the elements of an item in the array, e.g. pols[584] had 160 elements. So I would need to put a limit on the number of points that can be used to make a polygon e.g. 64. In which case I would need to change the script to pop up an error if a polygon has more that 64 points.

Regards, Iain

jeric_synergy
08-27-2012, 08:24 AM
Ok, so I used the lwo file to create an lscript. I would appear to be a limit in lscript with regard to the size of bytes used by the elements of an item in the array, e.g. pols[584] had 160 elements. So I would need to put a limit on the number of points that can be used to make a polygon e.g. 64. In which case I would need to change the script to pop up an error if a polygon has more that 64 points.
Regards, Iain
!!!? Don't have access right now, but I'm surprised any given poly in the source mesh had 160 elements (points). They are just standard fonts.

How many bytes are used in the storage of each vertex?

Perhaps that's the default array size, and it's possible to explicitly specify a larger array?

Thanks for looking into this! :beerchug:

iain_r
08-27-2012, 08:48 AM
H Jeric, It's the polygon information that is the problem and not the vertex details.

Example from your killer script of polygons with very large point count.

pols[584] = "1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160";
pols[585] = "584 743 742 741 740 739 738 737 736 735 734 733 732 731 730 729 728 727 726 725 724 723 722 721 720 719 718 717 716 715 714 713 712 711 710 709 708 707 706 705 704 703 702 701 700 699 698 697 696 695 694 693 692 691 690 689 688 687 686 685 684 683 682 681 680 679 678 677 676 675 674 673 672 671 670 669 668 667 666 665 664 663 662 661 660 659 658 657 656 655 654 653 652 651 650 649 648 647 646 645 644 643 642 641 640 639 638 637 636 635 634 633 632 631 630 629 628 627 626 625 624 623 622 621 620 619 618 617 616 615 614 613 612 611 610 609 608 607 606 605 604 603 602 601 600 599 598 597 596 595 594 593 592 591 590 589 588 587 586 585";

This would appear to be a limitation with the number of bytes used by elements in each array index in lscript, and I don't think that this can be increased in any way. I've tried with both 9.6 and 11 and I get the same results of crashing Modeler when I try to run the generated script. I used 64 bit versions of LW for my tests.

I'll see if there is another way of storing the polygon information.

Regards, Iain

jeric_synergy
08-27-2012, 09:41 AM
Oh, I see (I think): it's not the array size, it's the number of bytes each array slot can contain.

::taps temple pensively:: This must be a common issue/problem in programming, it's sorta like a buffer overrun. Techniques used to address those issues may bear on this particular problem.

I can think of some hacky approaches, but they're pretty awful and inelegant.

I believe you said before that arrays are very short term: IIRC, the total poly vertice limit is 64K. If arrays get recycled immediately, you'd only need one big array of 64K to accommodate the max possible vertcount.

Thanks for continuing to look into this! It's amazing, to me, that no-one did this before.

iain_r
08-28-2012, 05:19 AM
Hi Jeric,

A new create script file plus an example of your killer text. Managed to handle all 160 points for a polygon. It does take a little bit of time as it needs to do a couple of lookups in the file. Please be patient when you run the generated script.

Regards

Iain.

jeric_synergy
08-28-2012, 11:05 AM
Hi Jeric,
A new create script file plus an example of your killer text. Managed to handle all 160 points for a polygon. It does take a little bit of time as it needs to do a couple of lookups in the file. Please be patient when you run the generated script.
Iain.
Cool. What method did you use to get around the byte limit?

Thanks for sticking with this! :thumbsup:

(huh, that "K" had 160 points. Surprising!)

iain_r
08-28-2012, 12:11 PM
Hi Jeric,

I found an old article on the forums that gave me an some ideas, I just had to work out how to implement it in this scenario. If you look at how the data in the file is now created compared with a previous version you will see that the point id for each polygon is listed on it's own line. Another array holds how many points are in each polygon, then it's a case of lookups in the three arrays to get the complete polygon information.

The information in the article isn't in any of the docs, no surprise there.

The only thing that I would like to tidy up is providing a status for the build so that you don't think that it isn't doing anything. I did try a quick test with moninit but I must have put it in the wrong place. It's not in the current script. I need to work that little bit out.

Regards

Iain.

jeric_synergy
08-28-2012, 01:23 PM
Hi Jeric,
I found an old article on the forums that gave me an some ideas,

Link? (For the benefit of others.)



The information in the article isn't in any of the docs, no surprise there.
::cough:: online evolving crowdsourced documentation::cough:: :D :grumpy:

The only thing that I would like to tidy up is providing a status for the build so that you don't think that it isn't doing anything. I did try a quick test with moninit but I must have put it in the wrong place. It's not in the current script. I need to work that little bit out.
Regards
Iain.
I was going to suggest it -- always good of course to keep the user apprised of what the heck is going on. Short of that, a "This might take a while..." notice.

In accordance with Baker's Dilemma (see my sig):

I suggest that you automatically append an ".ls" to files generated by this utility. That confused me for a bit.

If you could make the generator utility launch the "Add Plugins" dialog, that would be slick.


Just as a reality check: my version of "Killer.ls" took 27 seconds to execute on my machine. 2467 points, 620 polys. Attached. I suspect the machinations required to accommodate larger polys slow down the routine. For the intended use, arbitrary primitive generation, that's probably not a real problem.

iain_r
08-29-2012, 05:01 AM
Hi,

Link for the resolution of the array problem

http://forums.newtek.com/showthread.php?t=31849&

Other bits will need to wait.

Regards

Iain,

jeric_synergy
08-29-2012, 08:59 AM
Hi,
Link for the resolution of the array problem
http://forums.newtek.com/showthread.php?t=31849&
Other bits will need to wait.
Regards
Iain,
Thanks for the link, Iain. I may work up a heavily commented version for educational purposes. :thumbsup:

No worries on time: it's not like you're getting paid for this. :hey:

I haven't done a speed comparison, but I've toyed with the concept of,

below a certain vert count, use the old/faster method, above, use the more-capable/slower method.
Or see if there's a reliable way to auto divide and remerge polys.

iain_r
08-29-2012, 09:50 AM
Ok,

So this version will put a default directory up using the PLUGINDIRS value from the content configuration plus a *.ls, remember to leave this on the file name that you choose.

It also has a progress bar and message, which may get displayed if the build takes a while. Short scripts don't have enough time to display the message.

I can't find any command to have the generated script automatically added as a plugin.

Regards,

Iain.

jeric_synergy
02-04-2013, 11:57 PM
BUMP: okay, just so I can find this damn thread again,

arbitrary primitives