| |
In lugnet.cad.dev, Erik Olson writes:
> I see now that your problem is difficult to solve. Sorry I tried to put it
> into a nutshell, Steve. My preference would be to design an auxiliary file
> for each case, and markup the LDRAW part in a very general way, so that
> future programs could address the same problem (replacing curvature, studs
> on/off) in their own way. Then there would not have to be a subpart, and
> real but alternate LDRAW lines wouldn't have to be hidden in a comment.
> Actually this IS like having an in-line subpart with just a comment around it:
>
> 0 pure.dat
> (ldraw code)
> 0
> 0 BEGIN SECTION STUD
> 1 16 0 0 0 1 0 0 0 1 0 0 0 1 stud2.dat
> 0 END SECTION STUD
> 0 BEGIN SECTION TUBE
> 1 16 0 0 0 2 0 0 0 1 0 0 0 2 ring3.dat
> 1 16 0 4 0 2 0 0 0 1 0 0 0 2 ring2.dat
> 1 16 0 4 0 6 0 0 0 20 0 0 0 6 4-4cyli.dat
> 0 END SECTION TUBE
>
> and an auxiliary file would specify how to replace those blocks:
>
> REPLACE SECTION STUD
> #if (STUDS)
> QUOTE STUD
> #end
> END
>
> REPLACE SECTION TUBE
> cylinder{<0,0,0>,<0,17,0>,13.001
> clipped_by{
> (more L3P/POV-Ray code)
> }
> END
>
> The STUD section quotes the original block, but conditionally.
> The TUBE section specifies a replacement.
>
>
> I'm sure I'm not the first one to propose a marking-up extension.....
>
> On namespace, yes, a namespace would mean a separate file library containing
> the same part names. It may be that a certain namespace is only enabled
> during printing, or when exporting to a renderer.
>
> Namespaces do not solve your problem, where you want abilities like a
> preprocessor macro, and one file.
Huh...? This is getting too complicated, lost me!
Most of you have seen what I have done with adding POV part descriptions to
parts. I believe that I was using them correctly with the "established" methods.
To make much change would be too complicated, I fear.
A few of my opinions on this;
a) Making a POV equivalent part file,
a1) To make a different part file is LGEO, this becomes duplication of
effort which for some people is simple and quick, others way too complicated.
a2) I have looked at some of the part descriptions in the LGEO parts file, I
have no idea of what half of that stuff means.
b) checking POV parts
b1) How would we check these parts for errors? The only POV render I have
is POV. It would take hours just to look for different visual errors.
So far, I do not know of anyone checking POV parts.
c) Is this really duplication of effort, or not?
c1) yes, in a way it is, however, the "Pirate" cannon I made took almost 2
days of calculating, entering and debugging. The POV code only took about 1
hour (start to finish). Sure, I could have done the whole cannon in about
10 minutes more time, but I wanted the part to still rely on as much of the
LDraw generated code as possible.
c2) What we do not want to happen is for parts to be made for POV that have
no Ldraw equivalent or a very poor subsitute, I can think of many that this
could happen to.
Please keep in mind that making a part with POV equivalents(or portions of)
are for eye candy pictures only.
What am I saying here, I'm not really sure, just my two cents worth.
When we get some idea of where we really want to go with this I might get
back to modeling parts.
Good luck,
Paul Easter
|
|
Message has 1 Reply:
 | | Re: Inline POV-Ray code?
|
| (...) I think where I want to go with it, is to keep things simple and limited. At least for now. Embedded POV-Ray code should not make references to L3P-defined objects or definitions. It should stick strictly with primitive operations. Maybe later (...) (22 years ago, 5-Mar-02, to lugnet.cad.dev, lugnet.cad.ray)
|
Message is in Reply To:
| | Re: Inline POV-Ray code? [DAT]
|
| I see now that your problem is difficult to solve. Sorry I tried to put it into a nutshell, Steve. My preference would be to design an auxiliary file for each case, and markup the LDRAW part in a very general way, so that future programs could (...) (22 years ago, 1-Mar-02, to lugnet.cad.dev, lugnet.cad.ray)
|
26 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
