.X3D file parser is way too slow

  • (2 Pages)
  • +
  • 1
  • 2

16 Replies - 1582 Views - Last Post: 10 November 2014 - 09:10 AM Rate Topic: -----

#1 Falcoshin   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 44
  • Joined: 31-August 14

.X3D file parser is way too slow

Posted 09 November 2014 - 11:41 PM

I've recently tried to write a file parser for the .x3d file type as it's one of the few 3d model types I can find written in easy to understand (and interpret) English. While it technically does work (or what I have so far), the issue is that it takes far too long (17 minutes) to parse just a part of the file (the vertices of the model).

This is the code for the object itself:

import java.io.*;
import com.sun.j3d.utils.geometry.*;
import javax.media.j3d.*;
import javax.vecmath.*;

public class ModelLoader {
    BranchGroup object = new BranchGroup();
    BufferedReader reader;
    String line = "start";
    
    public void load(String file){
        try{
            reader = new BufferedReader(new FileReader(new File(file)));
            while((line = reader.readLine()) != null){
                if (line.trim().startsWith("<Coordinate")){
                    line = line.trim().split("\"")[1];
                    Point3f points = new Point3f(); 
                    System.out.println(line.split(" ").length);
                    for (int i = 0; i < line.split(" ").length; i += 3){
                        points.x = Float.parseFloat(line.split(" ")[i]);
                        points.y = Float.parseFloat(line.split(" ")[i + 1]);
                        points.z = Float.parseFloat(line.split(" ")[i + 2]);
                    }
                }
            }
        }
        catch(IOException e){
            e.printStackTrace();
        }
    }
}


(If there are any remaining references to a writer in there, I apologize. They are not suppose to be there and were meant to help me test a so far untested theory I had on how to fix this that I will share later).

And here is a fraction of the part of the file I want to parse (the part this particular section is designed to detect):

<Coordinate point="-5.051000 -18.590000 -17.980001 -2.347000 -19.250002 -19.700001 -4.072000 -21.900000 -18.880001 -2.347000 -19.250002 -19.700001 -1.632000 -22.550001 -20.100002 -4.072000 -21.900000 -18.880001 -2.347000 -19.250002 -19.700001 -1.592000 -20.500000 -20.080002 -1.632000 -22.550001 -20.100002 -4.977000 -20.110001 -18.170002 -5.051000 -18.590000 -17.980001 -4.072000 -21.900000 -18.880001 -5.321000 -21.309998 -17.970001 -4.977000 -20.110001 -18.170002 -4.072000 -21.900000 -18.880001 -1.592000 -20.500000 -20.080002 -2.347000 -19.250002 -19.700001 -1.718000 -18.660002 -19.830002 -5.593000 -19.440001 -17.490000 -5.051000 -18.590000 -17.980001 -4.977000 -20.110001 -18.170002 -4.977000 -20.110001 -18.170002 -5.679999 -21.000000 -17.640001 -5.593000 -19.440001 -17.490000 -5.679999 -21.000000 -17.640001 -4.977000 -20.110001 -18.170002 -5.321000 -21.309998 -17.970001 -5.679999 -21.000000 -17.640001 -5.321000 -21.309998 -17.970001 -5.776000 -22.610001 -17.620003 -5.593000 -19.440001 -17.490000 -5.678999 -18.120001 -17.210001 -5.051000 -18.590000 -17.980001 -5.051000 -18.590000 -17.980001 -3.067000 -17.709999 -19.050001 -2.347000 -19.250002 -19.700001 -1.718000 -18.660002 -19.830002 -2.347000 -19.250002 -19.700001 -3.067000 -17.709999 -19.050001 -1.718000 -18.660002 -19.830002 -3.067000 -17.709999 -19.050001 -1.782000 -17.270002 -19.500002 -5.678999 -18.120001 -17.210001 -5.592999 -17.450001 -17.320002 -5.051000 -18.590000 -17.980001 -1.632000 -22.550001 -20.100002 -2.886000 -23.360003 -19.600002 -4.072000 -21.900000 -18.880001 -5.052000 -23.530001 -18.380001 -5.321000 -21.309998 -17.970001 -4.072000 -21.900000 -18.880001 -5.321000 -21.309998 -17.970001 -5.052000 -23.530001 -18.380001 -5.776000 -22.610001 -17.620003 -4.304999 -16.340000 -18.000002 -3.067000 -17.709999 -19.050001 -5.051000 -18.590000 -17.980001 -5.592999 -17.450001 -17.320002 -4.304999 -16.340000 -18.000002 -5.051000 -18.590000 -17.980001 -1.782000 -17.270002 -19.500002 -3.067000 -17.709999 -19.050001 -2.317000 -16.030001 -18.940001 -4.304999 -16.340000 -18.000002 -5.592999 -17.450001 -17.320002 -5.276999 -15.740000 -16.809999 -3.067000 -17.709999 -19.050001 -4.304999 -16.340000 -18.000002 -3.300000 -15.310000 -18.230001 -2.317000 -16.030001 -18.940001 -3.067000 -17.709999 -19.050001 -3.300000 -15.310000 -18.230001 -1.941000 -24.210001 -19.960001 -2.886000 -23.360003 -19.600002 -1.632000 -22.550001 -20.100002 -4.072000 -21.900000 -18.880001 -2.886000 -23.360003 -19.600002 -4.119999 -24.570000 -19.059999 -4.072000 -21.900000 -18.880001 -4.119999 -24.570000 -19.059999 -5.052000 -23.530001 -18.380001 -2.886000 -23.360003 -19.600002 -1.941000 -24.210001 -19.960001 -4.119999 -24.570000 -19.059999 -5.176000 -24.879999 -18.719999 -5.052000 -23.530001 -18.380001 -4.119999 -24.570000 -19.059999 -5.052000 -23.530001 -18.380001 -5.938000 -24.080000 -18.010002 -5.776000 -22.610001 -17.620003 -5.052000 -23.530001 -18.380001 -5.176000 -24.879999 -18.719999 -5.938000 -24.080000 -18.010002 -6.066000 -25.059999 -18.730001 -5.938000 -24.080000 -18.010002 -5.176000 -24.879999 -18.719999 -4.119999 -24.570000 -19.059999 -4.537000 -25.420000 -19.000002 -5.176000 -24.879999 -18.719999 -5.307000 -25.690002 -19.280003 -6.066000 -25.059999 -18.730001 -5.176000 -24.879999 -18.719999 -3.350000 -26.150002 -19.500002 -4.119999 -24.570000 -19.059999 -1.941000 -24.210001 -19.960001 -3.350000 -26.150002 -19.500002 -1.941000 -24.210001 -19.960001 -2.271000 -25.610003 -19.830002 -4.119999 -24.570000 -19.059999 -3.350000 -26.150002 -19.500002 -4.537000 -25.420000 -19.000002 -5.176000 -24.879999 -18.719999 -4.321000 -26.630001 -19.400002 -5.307000 -25.690002 -19.280003 -4.537000 -25.420000 -19.000002 -4.321000 -26.630001 -19.400002 -5.176000 -24.879999 -18.719999 -3.350000 -26.150002 -19.500002 -3.917000 -26.970003 -19.469999 -4.537000 -25.420000 -19.000002 -3.917000 -26.970003 -19.469999 -4.321000 -26.630001 -19.400002 -4.537000 -25.420000 -19.000002 -3.917000 -26.970003 -19.469999 -4.183000 -27.120003 -19.580000 -4.321000 -26.630001 -19.400002 -2.271000 -25.610003 -19.830002 -2.253999 -27.530003 -19.680000 -3.350000 -26.150002 -19.500002 -3.350000 -26.150002 -19.500002 -2.253999 -27.530003 -19.680000 -3.917000 -26.970003 -19.469999 -4.321000 -26.630001 -19.400002 -4.411000 -27.380001 -19.910000 -5.307000 -25.690002 -19.280003 -4.183000 -27.120003 -19.580000 -4.411000 -27.380001 -19.910000 -4.321000 -26.630001 -19.400002 -3.917000 -26.970003 -19.469999 -2.253999 -27.530003 -19.680000 -3.818000 -27.720001 -19.500000 -3.917000 -26.970003 -19.469999 -3.818000 -27.720001 -19.500000 -4.183000 -27.120003 -19.580000 -3.818000 -27.720001 -19.500000 -4.227000 -28.250002 -19.740000 -4.183000 -27.120003 -19.580000 -2.253999 -27.530003 -19.680000 -3.982000 -28.710001 -19.430002 -3.818000 -27.720001 -19.500000 -3.818000 -27.720001 -19.500000 -3.982000 -28.710001 -19.430002 -4.227000 -28.250002 -19.740000 -4.227000 -28.250002 -19.740000 -3.982000 -28.710001 -19.430002 -4.373000 -29.170002 -19.690001 -2.253999 -27.530003 -19.680000 -2.731000 -29.850002 -18.970001 -3.982000 -28.710001 -19.430002 -3.982000 -28.710001 -19.430002 -2.731000 -29.850002 -18.970001 -4.237000 -29.780003 -19.170002 -4.237000 -29.780003 -19.170002 -2.731000 -29.850002 -18.970001 -3.313000 -30.670000 -18.580000 -4.261000 -30.370003 -18.880001 -4.237000 -29.780003 -19.170002 -3.313000 -30.670000 -18.580000 -5.145000 -30.620003 -19.540003 -4.237000 -29.780003 -19.170002 -4.261000 -30.370003 -18.880001 -3.313000 -30.670000 -18.580000 -4.840000 -31.320000 -18.160002 -4.261000 -30.370003 -18.880001 -4.840000 -31.320000 -18.160002 -3.313000 -30.670000 -18.580000 -2.828000 -31.660000 -17.880001 -3.313000 -30.670000 -18.580000 -1.283000 -30.160000 -19.020002 -2.828000 -31.660000 -17.880001 -2.828000 -31.660000 -17.880001 -1.283000 -30.160000 -19.020002 -1.343000 -31.560001 -18.129999 -1.283000 -30.160000 -19.020002 -3.313000 -30.670000 -18.580000 -2.731000 -29.850002 -18.970001 -2.731000 -29.850002 -18.970001 -2.253999 -27.530003 -19.680000 -1.041000 -27.820004 -19.900002 -2.253999 -27.530003 -19.680000 -2.271000 -25.610003 -19.830002 -1.041000 -27.820004 -19.900002 -2.731000 -29.850002 -18.970001 -1.041000 -27.820004 -19.900002 -0.832200 -29.340004 -19.410002 -0.832200 -29.340004 -19.410002 -1.283000 -30.160000 -19.020002 -2.731000 -29.850002 -18.970001 -1.632000 -22.550001 -20.100002 -1.592000 -20.500000 -20.080002 -0.846800 -20.950003 -20.350000 -1.730000 -32.320004 -17.380001 -2.828000 -31.660000 -17.880001 -1.343000 -31.560001 -18.129999 -2.912000 -32.560005 -16.830002 -4.840000 -31.320000 -18.160002 -2.828000 -31.660000 -17.880001 -1.730000 -32.320004 -17.380001 -2.912000 -32.560005 -16.830002 -2.828000 -31.660000 -17.880001 -2.046000 -14.340000 -18.360001 -2.317000 -16.030001 -18.940001 -3.300000 -15.310000 -18.230001 -2.317000 -16.030001 -18.940001 -2.046000 -14.340000 -18.360001 -1.782000 -17.270002 -19.500002 -4.304999 -16.340000 -18.000002 -4.721000 -13.870000 -16.639999 -3.300000 -15.310000 -18.230001 -4.721000 -13.870000 -16.639999 -4.304999 -16.340000 -18.000002 -5.276999 -15.740000 -16.809999 -2.046000 -14.340000 -18.360001 -3.300000 -15.310000 -18.230001 -3.636000 -13.270001 -17.150002 -4.721000 -13.870000 -16.639999 -3.636000 -13.270001 -17.150002 -3.300000 -15.310000 -18.230001 -4.721000 -13.870000 -16.639999 -4.354000 -13.160001 -16.680002 -3.636000 -13.270001 -17.150002 -4.721000 -13.870000 -16.639999 -5.208000 -13.260001 -15.760000 -4.354000 -13.160001 -16.680002 -2.188000 -12.440000 -17.430002 -2.046000 -14.340000 -18.360001 -3.636000 -13.270001 -17.150002 -0.929000 -13.110000 -18.120003 -2.046000 -14.340000 -18.360001 -2.188000 -12.440000 -17.430002 -3.636000 -13.270001 -17.150002 -2.934000 -11.860001 -16.800001 -2.188000


...And it pretty much just goes on like that.

Anyway, here are some observations I've made about the file:

• The line in the file itself that contains all the vertices is all one giant string according to the file.
• There are apparently 18,000 vertices in all (according to the command at line 18).
• Unless Netbeans automatically terminates infinite loops after a certain amount of time, it is most definitely NOT an infinite loop as I have seen the program terminate on its own (after 17 minutes, though).

I had a theory that maybe organizing each vertex into its own line and then having the program switch to the next line when it's done reading that vertex might make the program run faster, but I'm not sure why it would, so I thought I'd come here in case that theory turned out to be a dead end.

Is This A Good Question/Topic? 0
  • +

Replies To: .X3D file parser is way too slow

#2 macosxnerd101   User is offline

  • Games, Graphs, and Auctions
  • member icon




Reputation: 12800
  • View blog
  • Posts: 45,992
  • Joined: 27-December 08

Re: .X3D file parser is way too slow

Posted 10 November 2014 - 12:01 AM

Is it a requirement that you write your own? There are existing solutions out there that are probably going to be better than yours. I'd check one of them out and use it for your own purposes.
Was This Post Helpful? 0
  • +
  • -

#3 Falcoshin   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 44
  • Joined: 31-August 14

Re: .X3D file parser is way too slow

Posted 10 November 2014 - 12:06 AM

I've tried that and they'll often not work the way I want them to (for example, the last time I tried using a 3rd party parser, it ended up playing the file's animations on launch instead of in response to user input). This is to make absolute sure everything in the file is stored and organized just the way I want it during runtime.

That and 3rd party parsers for 3d model types which store animation are surprisingly hard to find.
Was This Post Helpful? 0
  • +
  • -

#4 macosxnerd101   User is offline

  • Games, Graphs, and Auctions
  • member icon




Reputation: 12800
  • View blog
  • Posts: 45,992
  • Joined: 27-December 08

Re: .X3D file parser is way too slow

Posted 10 November 2014 - 07:33 AM

A cursory Google search turned up a number of results. I think you might be using the parser wrong if it's playing on start. Of course, sometimes, 3rd party tools aren't well documented. Still, I'm sure there is a decent enough tool for you to use out there.

https://www.google.c...-a&channel=fflb
Was This Post Helpful? 0
  • +
  • -

#5 Falcoshin   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 44
  • Joined: 31-August 14

Re: .X3D file parser is way too slow

Posted 10 November 2014 - 08:19 AM

Ok, so why is THIS one running so slowly?
Was This Post Helpful? 0
  • +
  • -

#6 macosxnerd101   User is offline

  • Games, Graphs, and Auctions
  • member icon




Reputation: 12800
  • View blog
  • Posts: 45,992
  • Joined: 27-December 08

Re: .X3D file parser is way too slow

Posted 10 November 2014 - 08:44 AM

Probably because you're parsing everything all at once.

In doing a bit of Googling, it looks like X3D is an XML technology. You could try using the standard Java DOM parser and go from there. The SAX and StAX parsers are also available.
Was This Post Helpful? 0
  • +
  • -

#7 Falcoshin   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 44
  • Joined: 31-August 14

Re: .X3D file parser is way too slow

Posted 10 November 2014 - 08:47 AM

What do you mean by parsing everything at once? Is the fact that all the information's on the same line really the problem?
Was This Post Helpful? 0
  • +
  • -

#8 macosxnerd101   User is offline

  • Games, Graphs, and Auctions
  • member icon




Reputation: 12800
  • View blog
  • Posts: 45,992
  • Joined: 27-December 08

Re: .X3D file parser is way too slow

Posted 10 November 2014 - 08:51 AM

Quote

while((line = reader.readLine()) != null){

Parsing everything at once.

And then having ~18k vertices to weed through is a lot of data to go through.
Was This Post Helpful? 0
  • +
  • -

#9 Falcoshin   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 44
  • Joined: 31-August 14

Re: .X3D file parser is way too slow

Posted 10 November 2014 - 08:54 AM

Then what technique should I use to speed up the process?
Was This Post Helpful? 0
  • +
  • -

#10 macosxnerd101   User is offline

  • Games, Graphs, and Auctions
  • member icon




Reputation: 12800
  • View blog
  • Posts: 45,992
  • Joined: 27-December 08

Re: .X3D file parser is way too slow

Posted 10 November 2014 - 08:55 AM

View Postmacosxnerd101, on 10 November 2014 - 10:44 AM, said:

Probably because you're parsing everything all at once.

In doing a bit of Googling, it looks like X3D is an XML technology. You could try using the standard Java DOM parser and go from there. The SAX and StAX parsers are also available.

Was This Post Helpful? 0
  • +
  • -

#11 Falcoshin   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 44
  • Joined: 31-August 14

Re: .X3D file parser is way too slow

Posted 10 November 2014 - 09:01 AM

So store the document in a variable or series of variables to read from later?
Was This Post Helpful? 0
  • +
  • -

#12 macosxnerd101   User is offline

  • Games, Graphs, and Auctions
  • member icon




Reputation: 12800
  • View blog
  • Posts: 45,992
  • Joined: 27-December 08

Re: .X3D file parser is way too slow

Posted 10 November 2014 - 09:02 AM

Just use an existing parser, which is very well documented. KYA's blog entries are excellent introductions.
Was This Post Helpful? 0
  • +
  • -

#13 Falcoshin   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 44
  • Joined: 31-August 14

Re: .X3D file parser is way too slow

Posted 10 November 2014 - 09:05 AM

Which blog should I be looking for?
Was This Post Helpful? 0
  • +
  • -

#14 macosxnerd101   User is offline

  • Games, Graphs, and Auctions
  • member icon




Reputation: 12800
  • View blog
  • Posts: 45,992
  • Joined: 27-December 08

Re: .X3D file parser is way too slow

Posted 10 November 2014 - 09:06 AM

Did you not read my previous posts? I already provided you with links...
Was This Post Helpful? 0
  • +
  • -

#15 Falcoshin   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 44
  • Joined: 31-August 14

Re: .X3D file parser is way too slow

Posted 10 November 2014 - 09:07 AM

Nevermind. Turns out I was right all along and putting each vertex into its own line speeds the program considerably.
Was This Post Helpful? 0
  • +
  • -

  • (2 Pages)
  • +
  • 1
  • 2