Thank you - I will wait.
Please use version 23.11.1.
Sample code to use InputStreamReader:
MemoryStream ms = new MemoryStream();
Scene scene = new Scene();
scene.save(ms, FileFormat.WAVEFRONTOBJ);
ms.seek(0, Stream.SEEK_SET);
BufferedReader br = new BufferedReader(new InputStreamReader(ms.getInputStream()));
System.out.println( br.readLine());
System.out.println( br.readLine());
System.out.println( br.readLine());
System.out.println( br.readLine());
System.out.println( br.readLine());//returns null
1 Like
GREAT, THAT WORKS - thank you!
BUT…another “strange” thing: when rendered the model is flipped 90 degrees on X and Y/Z axis (this is one of the actual models I’m really using, not some example file, tho the structure is absolutely the same: DAE outputted from the Blender).
This is how it looks in LEGO LDD editor:
This is how it looks when the DAE is opened inside the Blender:
This is how it looks when the model is rendered in my JAVA app as original Collada DAE file (correct rotation):
And this is how it looks when redered in my JAVA app using Aspose3D streamed version (DAE to OBJ stream):
I do understand I can correct it after the process myself but it definitely is wrongly interpreted during the stream conversion - is it another bug or do I omitted some important additional value to add to the Aspose3D once again (if so, can you tell me which one, please)?
You could even add there some new options like some really just a simple geometry manipulation (scale, rotation, placement)…just saying.
Instead of links of the images, can you please upload them here? Meanwhile, we are checking your concerns and will let you know about our feedback soon.
What??? You want me to upload the images?
BTW you can test this even with the test DAE file you already have as it will be flipped too (I just test that).
We requested to upload images because due to some network restrictions, we were not able to see the images that you posted. Nevertheless, we will try and replicate the issue that you posted will address it accordingly. We apologize for the inconvenience.
Aha, now I understand, so here are the images in the sequence as described in the post.
This is how it looks in LEGO LDD editor:
01.jpg (44.0 KB)
This is how it looks when the DAE is opened inside the Blender:
02.jpg (17.8 KB)
This is how it looks when the model is rendered in my JAVA app as original Collada DAE file (correct rotation):
03.jpg (14.2 KB)
And this is how it looks when redered in my JAVA app using Aspose3D streamed version (DAE to OBJ stream):
04.jpg (12.8 KB)
Please use explicit ObjSaveOptions than the default settings:
ObjSaveOptions opt = new ObjSaveOptions();
opt.setFlipCoordinateSystem(true);
Unfortunately, that solved the problem only partially as it is still flipped on Y axis by 180 degree = front section is facing backward (X axis was cured tho), see:
!deleteme.jpg (14.8 KB)
.
.
.
.
.
BTW as a side note:
A javadoc for the Aspose3D contains/shows NO INFO ABOUT ITS FUNCTIONS AT ALL - do you know that (well, it looks like that at least in my NetBeans 13 where I add the corresponding javadoc to the JAR but it still shows absolutely no info about any of the native Aspose3D functions/methods or call it anyhow you want…like when I first define ObjSaveOptions opt = new ObjSaveOptions(); and then continue and write opt. list of available “functions/methods” show up and when I select any of those specific to Aspose3D every single one has line saying “Java doc not found”)?
What comes to my mind: did not it need to be recompiled too for the JDK8? Just guessing as I saw something about it is different starting from JDK9 onward compared to JDK8…in this article: https://stackoverflow.com/a/53099603/19018243
Or may it be that once again it is me doing something wrong here? I understand it the way that all I have to do to have javadoc for the specific JAR library is to “chain” them together - in NetBeans13 it is RMB specific JAR library, then EDIT and there point to the javadoc file for that JAR - is that correct?
@luborablahova
Can you share this dae file for us to reproduce this issue?
We’ve logged the javadoc issue into our issue tracking system, the issue ID is
THREEDJAVA-312
Sure, here it is that specific DAE file (beware tho: it is quite big about 36MB once unzipped as it is a hires version of the brick used for the my JAVA rendering app compared to lowres one used in the LDD editor):
3844.zip (8.6 MB)
@luborablahova
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): THREEDJAVA-313
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
Issue Statuses saying ALL ARE SOLVED but AFAICT you did not provided solution here as before - did something changed, or where can I find those updated/solved files, please? Confused… 
We are sorry that auto-notification for the resolved tickets could not reach this thread. Nevertheless, we will be more careful next time. All of the tickets have been resolved in 23.12 version of the API. JDK8 support was added in 23.11 version.
1 Like
Please use the latest version 23.12, it redesigned the implementation of flipping coordinate system.
Still use the same save option
ObjSaveOptions opt = new ObjSaveOptions();
opt.setFlipCoordinateSystem(true);
Since 23.12 it’s fully customizable to choose the axis system in obj export, you can find more information in our Aspose.3D for Java 23.12 Release Notes.
1 Like
Thank you for your quick answer guys!
I can now confirm that the render is finally OK as it should…
…BUT it still does not know about the javadoc: when I write, let’s say scene. (after I initialized it first, of course) it gives me a list of possible functions/methods for scene and when I select any of those it says it has no javadoc associated with although I did associated the correct javadoc for the latest version via RMB aspose jar → edit → javadoc (I am still using a bit older NetBeans 13 - I cannot update to the newest version cos from the 14+ they introduced totally different way of representing the syntax/code, I hate it, totally bad decision…well, just saying explaining why I cannot and won’t not update my NetBeans anytime soon).
Can anyone of you confirm this is still the issue (cos it looks like it to me)?
@lex.chou Can you give another useful simple example of how to use/implement that flipping coordinate system, please?
Currently the jdk8 version jdk was built using the same toolchain as we used to build normal version, in the next version we’ll use old JDK with custom tool to build javadoc and use old NetBeans to verify.
OBJ format does not have default coordinate system in specification nor explicit definition of coordinate system, that’s why we introduced the manually option to specify the axis system.
Another sample code:
//construct a right-handed axis system with +y as up and -z as front
Axis up = Axis.Y_AXIS;
Axis front = Axis.NEGATIVE_Z_AXIS;
AxisSystem axisSystem = new AxisSystem(CoordinateSystem.RIGHT_HANDED, up, front);
ObjSaveOptions opt = new ObjSaveOptions();
//use the custom axis system to flip coordinate
opt.setAxisSystem(axisSystem);
//set this to true, will convert mesh's position/normal from source axis system to custom axis system
//source axis system is defined by scene.getAssetInfo().getCoordinateSystem(), scene.getAssetInfo().getUpVector(), scene.getAssetInfo().getFrontVector()
opt.setFlipCoordinateSystem(true);
1 Like
Wow, that option really look great indeed + thanks so much for your another visual example of HOW-TO!!! Appreciated a lot! 
I will test it later today as now I am busy…