Java DAE to OBJ as stream behaves strangely (aspose-3d-19.3.jar/JDK8)

Aspose.3D Product Family
1

I am converting Collada DAE file exported from the Blender 3.6.5 to Wavefront OBJ as stream wanting to pass it to InputStreamReader, but it seems I am doing something wrong or at least misunderstood Aspose’s stream.getInputStream() option, as normally my code works just fine when I am getting that InputStream from actual existing OBJ file as FileInputStream (I did try to actually save it to an OBJ file instead of a stream and then getting the FileInputStream from it and it works that way, but it’s not what I want, I want direct stream option, of course!), thus I am suspecting abovementioned.

So, I do the obvious magic with the Aspose.3D library:

  • opening my DAE file (opens OK)
  • setting my options (basically just the option to get rid of the MTL file with setEnableMaterials(false))
  • saving it as Aspose’s Stream (saves to Stream OK, tested by checking its length, size and even as array to physically print the content to be 100% sure it is OK)

My next step is what I consider to be a logical one: stream.getInputStream(), but for some reason it (its content) seems to be “null/empty/nada/nichts” as I am getting this error in my NetBeans:

java.io.IOException: java.io.IOException: Underlying input stream returned zero bytes

The block code that reads the content of the converted DAE to OBJ uses the “classic” approach, so the part of my code that matters looks like this (all works fine up until the InputStreamReader inside the try() section):

//-------------------- DEA TO OBJ (AS STREAM) --------------------
Scene scene = new Scene();
scene.open(stringAbsPthToInputFIle);
ObjSaveOptions options = new ObjSaveOptions();
options.setEnableMaterials(false);
try ( MemoryStream dstStream = new MemoryStream()) {
    scene.save(dstStream, options);
    
    // THIS VERY LINE SEEMS TO BE THE PROBLEM
    try ( InputStreamReader file = new InputStreamReader(dstStream.getInputStream(), "UTF-8")) {
        BufferedReader bf = new BufferedReader(file);
        String line;
        while ((line = bf.readLine()) != null) {
            // MY OTHER CODE HERE DEALING WITH THE SPECIFIC LINE FROM THE OBJ FILE
        }
    }
}

I have no clue why is that - am I doing something wrong here or is it a bug in this Aspose.3D version?

If so, can anyone show me (post) actual functional version of my code, please?

2

@luborablahova

Would you kindly try to use the latest version of the API and see if issue still occurs in your environment. If it does, can you please share the sample file in .zip format so that we can test the scenario in our environment and address it accordingly.

3

As I said in my other post: I CAN NOT USE ANY VERSION OF Aspose.3D NEWER THAN v19.3, cos that is the last one being compiled using JDK8 which is the version I am using and compiling absolutely all my apps with NetBeans13.

That would require for me huge redesign of all of my apps which I won’t do just to be able run your newer versions cos for some reason you are not providing files compiled with JDK8 for ppl like me that still are using JDK8 (and I would say it is the biggest part of Java users).

Main reason why I won’t be using any newer version is that newer versions of Java (and I did try JDK21 and JDK9 only to run almost immediately back to old great JDK8) introducing hell of a lot problems to all my existing Java code, even some that has no functional replacement at the moment like deploying native dll from inside the JAR file itself at runtime…so no, I would not as I can not, sorry.

As for the test file, sure, here it is:
stream.7z (665.0 KB)

4

@luborablahova

We requested to test using the latest version of the API only to be sure whether the issue is related to specific version of the API. We are sorry if it created an impression that we did not even read the entire post. Please note that we provide support on the basis of the latest version of the API because any issue reported in the older version is resolved in the higher and the latest version of the API. Therefore, we always recommend using the current latest available version because it contains maximum fixes and the enhancements.

We have gone through the entire description of the scenario you shared and have generated an investigation ticket as THREEDJAVA-299 in our issue management system. We will look into the details of the ticket and inform you as soon as it is resolved. We will share our feedback with you in this forum thread once the ticket is closed. We appreciate your patience in this regard. Please spare us some time.

We apologize for the inconvenience caused.

5

Oh, I am sorry if I sounded angry or something, no, it was just a bit of a frustration that I cannot move to my next step in my app cos I have to wait for this, nothing else, so all is good with me and thank you for your answer - I will most definitely wait how and if your team would solve this issue.

But if I may ask once again: as I said, I can use only builds that were made with version major 52 which is JDK8 I am using, but your latest builds are made with version major 53 which is JDK9 - well, at least that is how my NetBeans13 is telling me when I tried to use your latest builds, thus my question here: would it be possible for your team to also make builds compiled using/with JDK8 which is still the mostly used Java version out there so I could actually use your newest builds?

I would think about two section in the jar download section of your website, where there would be build with mv53 (JDK9) at the top, and there could be - below it - build made with older yet mostly used mv52 (JDK8), so one can chose what it suits him, hm?

6

@luborablahova

Thanks for the explanation. Yes, we can try to publish a JDK8 compatible version of the API. However, it will lack some features. We will be looking into this request and let you know once we have some updates.

1 Like
7

@luborablahova
Rendering now necessitates lwjgl.jar, which isn’t compatible with JDK8. Due to this, we had to raise the minimum JVM version. However, we can create a specialized build compatible with JDK8, albeit without rendering capabilities.
We’ll let you know once we fixed this issue.

1 Like
8

Oh guys - both of you - this is prolly the best news this year I got so far, thank you so much for this!!!

I do not need rendering ability so absolutely no miss on my side, and I guess most of the ppl using this library using it mainly for the 3D manipulation abilities (in fact you are the only one known Java lib which can do this, amazing stuff) as there are separate free Java renderers thus one can quite easily use those in combo with your library…

Maybe you could just list those missing functions in the JDK8 build under the download section so one would know what he would missing if he uses JDK8 build - I think that would be sufficient info for those willing to use such build.

BTW I am author of one such renderer myself…well, actually a advanced GUI for a renderer bringing many new abilities to the renderer itself (tho it is only my own personal internal tool for my quasy-business).

Can not wait to see the release of JDK8 builds of your newest version - looking forward to that impatiently!

9

@luborablahova

Thanks for your kind feedback. We will surely inform you in this forum thread once the ticket is resolved.

1 Like