Set line width in COLLADA for viewing in Google Earth

I can set up 3D lines in a COLLADA .dae file and view them in Google Earth, but they are really thin and very hard to see over Colorado. How can I set the line width to something other than the default of 1 (meter?)? I have located the line_width tag in the COLLADA documentation, but it does not seem to do anything no matter where I put it.

Here is my .dae file Lines-blue.dae.

<?xml version="1.0"?>
<COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.1">
  <asset>
    <contributor>
      <author>Carl Drews</author>
      <authoring_tool>Assimp Collada Exporter</authoring_tool>
    </contributor>
    <created>2000-01-01T23:59:59</created>
    <modified>2000-01-01T23:59:59</modified>
    <unit name="meter" meter="1" />
    <up_axis>Z_UP</up_axis>
  </asset>
  <library_effects>
    <effect id="m0DefaultMaterial-fx" name="m0DefaultMaterial">
      <profile_COMMON>
        <technique sid="standard">
          <phong>
            <emission>
              <color sid="emission">0   0   0   1</color>
            </emission>
            <ambient>
              <color sid="ambient">0.05   0.05   0.05   1</color>
            </ambient>
            <diffuse>
              <color sid="diffuse">0   0   1   1</color>
            </diffuse>
            <specular>
              <color sid="specular">0   0   0   1</color>
            </specular>
            <shininess>
              <float sid="shininess">16</float>
            </shininess>
            <reflective>
              <color sid="reflective">0   0   0   0</color>
            </reflective>
            <transparency>
               <float sid="transparency">0.5</float>
            </transparency>
          </phong>
        </technique>
	<extra>
          <technique profile="GOOGLEEARTH">
            <double_sided>1</double_sided>
            **<line_width>1200.0</line_width>**
          </technique>
	</extra>
      </profile_COMMON>
    </effect>
  </library_effects>
  <library_materials>
    <material id="m0DefaultMaterial" name="m0DefaultMaterial">
      <instance_effect url="#m0DefaultMaterial-fx"/>
    </material>
  </library_materials>
  <library_geometries>
    <geometry id="meshId0" name="meshId0_name" >
      <mesh>
        <source id="meshId0-positions" name="meshId0-positions">
          <float_array id="meshId0-positions-array" count="36">
		  0 0 0
		  12000 0 0
		  6000 6000 6000
		  
		  12000 0 0
		  12000 12000 0
		  6000 6000 6000
		  
		  12000 12000 0
		  0 12000 0
		  6000 6000 6000
		  
		  0 12000 0
		  0 0 0
		  6000 6000 6000
		  </float_array>
          <technique_common>
            <accessor count="12" offset="0" source="#meshId0-positions-array" stride="3">
              <param name="X" type="float" />
              <param name="Y" type="float" />
              <param name="Z" type="float" />
            </accessor>
          </technique_common>
        </source>
        <source id="meshId0-normals" name="meshId0-normals">
          <float_array id="meshId0-normals-array" count="36">
		  0 -0.5 0.5
		  0 -0.5 0.5
		  0 -0.5 0.5
		  
		  -0.5 0 0.5
		  -0.5 0 0.5
		  -0.5 0 0.5
		  
		  0 0.5 0.5
		  0 0.5 0.5
		  0 0.5 0.5
		  
		  -0.5 0 0.5
		  -0.5 0 0.5
		  -0.5 0 0.5
		  </float_array>
          <technique_common>
            <accessor count="12" offset="0" source="#meshId0-normals-array" stride="3">
              <param name="X" type="float" />
              <param name="Y" type="float" />
              <param name="Z" type="float" />
            </accessor>
          </technique_common>
        </source>
        <vertices id="meshId0-vertices">
          <input semantic="POSITION" source="#meshId0-positions" />
          <input semantic="NORMAL" source="#meshId0-normals" />
        </vertices>
        <lines count="4" material="theresonlyone">
          <input offset="0" semantic="VERTEX" source="#meshId0-vertices" />
          <vcount>3 3 3 3</vcount>
          <p>0 1 2
		  3 4 5
		  6 7 8
		  9 10 11
		  </p>
        </lines>
      </mesh>
    </geometry>
  </library_geometries>
  <library_visual_scenes>
    <visual_scene id="myScene" name="myScene">
      <node id="STL_BINARY" name="STL_BINARY">
        <matrix>1 0 0 0
		        0 1 0 0
				0 0 1 0
				0 0 0 1</matrix>
        <instance_geometry url="#meshId0">
          <bind_material>
            <technique_common>
              <instance_material symbol="theresonlyone" target="#m0DefaultMaterial"/>
            </technique_common>
          </bind_material>
        </instance_geometry>
      </node>
    </visual_scene>
  </library_visual_scenes>
  <scene>
    <instance_visual_scene url="#myScene" />
  </scene>
</COLLADA>

Here is the KML fragment that includes the COLLADA Model:

<Style id="WideLine">
  <LineStyle>
    <width>100</width>
  </LineStyle>
</Style>

<Placemark>
  <name>Experimental white lines floating over Boulder.</name>
  <description>Model created by Carl Drews - November 18, 2022.</description>

  <Camera>
    <longitude>-105.1000</longitude>
    <latitude> 40.0650</latitude>
    <altitude>2000</altitude>
    <tilt>90.00</tilt>
    <heading>-90.00</heading>
  </Camera>

  <Style id="default">
    <styleUrl>#WideLine</styleUrl>
  </Style>

  <Model id="model_7">
    <altitudeMode>relativeToGround</altitudeMode>
    <Location>
      <longitude>-104.9000</longitude>
      <latitude> 39.7000</latitude>
      <altitude>1000</altitude>
    </Location>
    <Orientation>
      <heading>0</heading>
      <tilt>0</tilt>
      <roll>0</roll>
    </Orientation>
    <Scale>
      <x>1</x>
      <y>1</y>
      <z>1</z>
    </Scale>
  <Link>
    <href>Lines-blue.dae</href>
  </Link>
  </Model>
  <TimeSpan>
    <begin>2021-04-09T00:00:00Z</begin>
    <end>2021-04-11T00:00:00Z</end>
  </TimeSpan>
</Placemark>

These lines in 3D space are supposed to trace the contours of 3D isosurfaces that I have already created with COLLADA and displayed with Google Earth. But the lines won’t show up unless they are thicker or wider. I could create lines in pure KML (no .dae) but I don’t think they will lay down on my isosurfaces accurately enough.

Thank you for any assistance you can provide.

Here is a screen shot to clarify. The thin blue lines run from roughly Glendale to Buckley AFB and then on to Rocky Mountain Arsenal.

Hmm, I don’t know a lot about COLLADA and Google Earth (GE), but it looks like you are using a GE specific extension for the line width - assuming that is the way to do that it feels like a bug in the GE renderer. Line width is often specified in pixels, have you tried some values in the 1-10 range?
Also, KML has support for line width (no idea if it works though :wink: ) - can you use that instead of COLLADA?

Here is a simple example containing a 3-segment LineString in KML instead of COLLADA. Google Earth supports line width 4 pixels, and these lines show up nicely.

My concern about accuracy with COLLADA isosurfaces in the original post remains. Also note that the real application will have tens of thousands of LineStrings, so KML performance may be in issue.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">
<Document>
	<name>Multi-segment line.kml</name>
	<Style id="outline123">
		<LineStyle>
			<color>ffffff00</color>
			<width>4</width>
		</LineStyle>
	</Style>

	<Placemark id="Outline12345">
		<name>Multi-segment line</name>
		<gx:TimeSpan>
			<begin>2021-04-09</begin>
			<end>2021-04-10T01:00:00Z</end>
		</gx:TimeSpan>
		<styleUrl>#outline123</styleUrl>
		<LineString id="line67890">
			<altitudeMode>absolute</altitudeMode>
			<coordinates>
				-105.6426,39.5876,4313 -105.616,40.2529,4338 -105.1692,40.1016,1555 -105.6426,39.5876,4313 
			</coordinates>
		</LineString>
	</Placemark>
</Document>
</kml>

Here is the KML experiment showing a pyrocumulus plume of smoke from the Williams Flats Fire in August 2019. The green (and nested yellow) isosurfaces are created with COLLADA 3D models and rendered in Google Earth. The gridded cage (wireframe) around the isosurfaces is built in KML with LineStrings of width=1 pixel. The purpose of the white grid lines is to bring out the 3D contours better.

The grid cage does not line up accurately with the edges of the COLLADA triangles; see upper left, below the image title. It is the same Cartesian-to-polar-coordinates conversion, but there is some difference in accuracy between COLLADA and whatever calculation Google Earth carries out in the viewer. This inaccuracy is why I would prefer to express both the isosurfaces and the grid lines in COLLADA.

The line width=1 pixel in KML looks satisfactory for visibility. I will try creating the grid cage in COLLADA and see if the paired 3D elements line up better.

The KML file size increases from 600 Kb to 20 Mb. It takes about 16 seconds to load the KML file, but the performance is satisfactory after that (zooming, panning).

It would be nice to know where the line_string parameter belongs in COLLADA and how to use it properly. I want to avoid requiring my users to squint at their screens.

Here is the wireframe as expressed in a COLLADA .DAE file. As anticipated, the triangle-based isosurfaces do indeed line up better with the white grid lines of the wireframe. Compare the upper and left edges of the pyrocumulus plume to see the improvement.

I will stick with the COLLADA implementation. Just in case anyone asks me to make the wireframe a little thicker, please let me know here how to increase the line_width from the default 1.0 pixels.

I have placed the Python solution into a public GitHub repository:
https://github.com/NCAR/Marching-Cubes

This implementation of Marching Cubes is described by a peer-reviewed paper included in the Proceedings of the Improving Scientific Software conference held at NCAR in Boulder, Colorado during April 4-8, 2022. Title: Marching Cubes Without Lookup Cases: Crawl the Edge Crossings Instead. Marching Cubes (Drews 2022) begins on page 19.

Citation: Hu, W., Vanderwende, B., Mickelson, S., & Nusbaumer, J. (Eds.). (2022). Proceedings of the 2022 Improving Scientific Software Conference (No. NCAR/TN-574+PROC). doi:10.5065/98kd-b491

Published Version: http://dx.doi.org/10.5065/98kd-b491

Link at NCAR OpenSky: https://opensky.ucar.edu/islandora/object/technotes%3A598