Re: [Update REQ 6152]: OOGL->VRML

[daemon]

> 1) Did you set the initial perspective of the data in the OOGL 
> file before converting it to VRML or did you do it after running oogl2vrml?

Well -- oogl2vrml doesn't try to do anything about specifying a viewpoint
in the file it generates.  So you could either try to post-process the
oogl2vrml output to provide a viewpoint if you can tell where it should be,
and/or normalize the OOGL data to be viewable from the default place.
Not sure where that would be, but I'll bet that fitting it into a
unit ball surrounding the origin would do.  Maybe this could be made
an option to oogl2vrml.  If you can see a nice way to deal with this,
let us know.

> 2) I've attached the following 2 files and they complain about a
> 75th polygon problem  out of 76 in the conversion. Is this an OOGL
> problem or a VRML problem?

It seems to be a problem with the OOGL file; I see several:

  - long lines in the OFF objects are still split at arbitrary points --
	something is deciding that the line is too long (300-character limit?)
	and inserting a line break.  For example, the last few lines of the
	file read:
4 146 147 1 0 0.000000 1.000000 1.000000 1
74 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 100 102 104 106 108 110 112 114 116 118 120 122 124 126 128 130 132 134 136 138 140 142 144 146 0.000000 1.
000000 1.000000 1
74 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 83 85 87 89 91 93 95 97 99 101 103 105 107 109 111 113 115 117 119 121 123 125 127 129 131 133 135 137 139 141 143 145 147 0.000000 1.
000000 1.000000 1

	Note the line(s) beginning with "74" end with "1.", and the following
	lines read "000000 1.000000 1".

  - some of the OFF objects still don't have "OFF" keyword headers
	(this isn't fatal, but it's a good idea to put them there)
  - EACH component of the LIST should be enclosed in { braces }.
	This isn't fatal either in this case, but braces *are* needed
	to enclose some object types, so it's best to consider them required:

LIST
{
  appearance { ... }
  OFF
  8 6 0
  ...
}
{
  appearance { ... }
  ...
}
{ ... and so on ...
}