Orangy Tang
|
 |
«
Posted
2010-12-20 11:45:42 » |
|
Does anyone know if there's any software 3d engines for java other than JCPT? I need ortho rendering and JPCT doesn't support it.  |
|
|
|
|
gouessej
|
|
«
Reply #1 - Posted
2010-12-20 11:57:07 » |
|
Does anyone know if there's any software 3d engines for java other than JCPT? I need ortho rendering and JPCT doesn't support it. JavaGL used in Tesseract. It is open source... |
|
|
|
|
Orangy Tang
|
|
«
Reply #2 - Posted
2010-12-20 12:51:49 » |
|
Does anyone know if there's any software 3d engines for java other than JCPT? I need ortho rendering and JPCT doesn't support it. JavaGL used in Tesseract. It is open source... Looks interesting, but doesn't seem to support texturing? |
|
|
|
Games published by our own members! Check 'em out!
|
|
|
|
|
Roquen
|
|
«
Reply #4 - Posted
2010-12-21 18:06:53 » |
|
I'm missing something: why software renderer?
|
|
|
|
|
|
DzzD
|
|
«
Reply #5 - Posted
2010-12-21 18:43:08 » |
|
depending on your need... 3DzzD can "simulate" ortho, basically you have to put your object very far from the camera and set it with a high zoom, it is possible with 3DzzD in software mode because it use a very high precision in depth buffer (cant explain here but it is more than double), this means that your objects can be very very far from the camera without any depth buffer error and then look as ortho rendering |
|
|
|
|
Orangy Tang
|
|
«
Reply #6 - Posted
2010-12-21 18:45:04 » |
|
I'm missing something: why software renderer?
Because now I've ironed out all the big bugs for Tectonicus, the number one "bug" report is people trying to use it on headless server boxes which don't have an opengl-capable graphics card. Hence a software renderer as well as a hardware renderer (even if it is a bit slower) is on my todo list, if it can be done without too much effort. Processing looks like the best option at the moment, even it it does use a totally different API. |
|
|
|
|
Orangy Tang
|
|
«
Reply #7 - Posted
2010-12-21 18:46:28 » |
|
depending on your need... 3DzzD can "simulate" ortho, basically you have to put your object very far from the camera and set it with a high zoom, it is possible with 3DzzD in software mode because it use a very high precision in depth buffer (cant explain here but it is more than double), this means that your objects can be very very far from the camera without any depth buffer error and then look as ortho rendering Yeah, this was the suggested workaround for using JPCT, but since it's not proper ortho it'll cause lots of seams between different tiles so it'll look ugly as sin. |
|
|
|
ryanm
« League of Dukes » Senior Member  Projects: 1
Used to be bleb
|
|
«
Reply #8 - Posted
2010-12-21 19:23:40 » |
|
Could you pre-render blocks and just composite the results in 2D?
|
|
|
|
|
|
DzzD
|
|
«
Reply #9 - Posted
2010-12-21 19:34:32 » |
|
depending on your need... 3DzzD can "simulate" ortho, basically you have to put your object very far from the camera and set it with a high zoom, it is possible with 3DzzD in software mode because it use a very high precision in depth buffer (cant explain here but it is more than double), this means that your objects can be very very far from the camera without any depth buffer error and then look as ortho rendering Yeah, this was the suggested workaround for using JPCT, but since it's not proper ortho it'll cause lots of seams between different tiles so it'll look ugly as sin. did you already try it ? (I cant really see what will not work well, you mean seams between rendered patch ?) |
|
|
|
Games published by our own members! Check 'em out!
|
|
|
Orangy Tang
|
|
«
Reply #10 - Posted
2010-12-21 19:35:27 » |
|
For a range of reasons that's not practical I'm afraid. Mostly because the lighting would mean having a huge amount of pre-rendered blocks, but it also makes different camera angles a pain to deal with. DzzD: Tectonicus renders a minecraft map by drawing thousands of individual output tiles (like this one). Each tile is a single 'frame', with a specially positioned ortho camera. If the projection isn't ortho then adjacent tiles won't line up correctly. |
|
|
|
|
DzzD
|
|
«
Reply #11 - Posted
2010-12-21 20:13:23 » |
|
ok, I did not think of this at first, you may be right but a real test case would be nice to be sure, for my own knowledge I will try to see if two grid rendered can fit perfectly ( the key is to reduce the perspective error to less than one pixel, so if possible, using something like a grid size of maybe 1cm and a camera 1Km far and a full antialias, should not give a big different result than a real ortho, but inded need to try to be sure if it is really possible and that the rendering look nice).
NB : in case it does really not work with a false ortho (far perspective) rendering, a solution to avoid problem maybe is when merging your tiles is to render them twice their requiered render size and once merged reduce the final image size (antialias)
|
|
|
|
|
Orangy Tang
|
|
«
Reply #12 - Posted
2010-12-22 02:21:54 » |
|
If you can show a practical example of 'fake' ortho that can be successfully tiled together as well as ortho i will be genuinely amazed (and I mean *properly* tiled over an infinite grid, not just for a few adjacent tiles). Frankly I still don't properly understand the reasons why 3DzzD and JCPT don't have a proper ortho mode. In my mind it's just a different projection matrix (ie. data only difference).  |
|
|
|
|
SimonH
|
|
«
Reply #13 - Posted
2010-12-22 02:50:25 » |
|
In my mind it's just a different projection matrix (ie. data only difference). I was thinking that too: isn't it just the projection matrix? Both DzzD and EgonOlsen are really nice guys - maybe ask for a custom build? |
|
|
|
|
EgonOlsen
|
|
«
Reply #14 - Posted
2010-12-22 07:58:17 » |
|
In jPCT, culling would be affected by getting too pessimistic, but that doesn't really hurt. But perspective correction would kick in anyway and the results wouldn't be correct. As far as non-textured, unlit polygons are concerned, it's simply the projection matrix. Regarding texturing, it's not.
|
|
|
|
|
DzzD
|
|
«
Reply #15 - Posted
2010-12-22 11:16:51 » |
|
Frankly I still don't properly understand the reasons why 3DzzD and JCPT don't have a proper ortho mode. In my mind it's just a different projection matrix (ie. data only difference). same for 3DzzD, different projection are easy for vertices, problem come with mapping/lighting, the main difference is that pixels shader ( texturing, lighting or any per pixel effect ) are NOT linear for perspective projection, while they are for orthodromic projection. |
|
|
|
|
Orangy Tang
|
|
«
Reply #16 - Posted
2010-12-22 11:27:18 » |
|
How much error are we talking about? Because I'm looking at the Processing texture example and there's some warpage of the texture in a perspective view, so I guess they're not doing perspective correct mapping, but what's the error like the other way? Is there a simple way I can actually knock up a 'proper' ortho screen in 3DzzD or JCPT and see if the error is acceptable or not? If it's no worse than the Processing warpage then it's probably acceptable, especially as for my usage (Minecraft levels) the tessalation is quite high in the first place. |
|
|
|
|
Matzon
|
|
«
Reply #17 - Posted
2010-12-22 11:38:22 » |
|
I'm missing something: why software renderer?
Because now I've ironed out all the big bugs for Tectonicus, the number one "bug" report is people trying to use it on headless server boxes which don't have an opengl-capable graphics card. Hence a software renderer as well as a hardware renderer (even if it is a bit slower) is on my todo list, if it can be done without too much effort. Processing looks like the best option at the moment, even it it does use a totally different API. did xvfb with mesa not work? |
|
|
|
|
Orangy Tang
|
|
«
Reply #18 - Posted
2010-12-22 11:43:13 » |
|
I'm missing something: why software renderer?
Because now I've ironed out all the big bugs for Tectonicus, the number one "bug" report is people trying to use it on headless server boxes which don't have an opengl-capable graphics card. Hence a software renderer as well as a hardware renderer (even if it is a bit slower) is on my todo list, if it can be done without too much effort. Processing looks like the best option at the moment, even it it does use a totally different API. did xvfb with mesa not work? It does, but: 1. I'm tired of getting "bug" reports and having to say "install Xvfb" all the time. People don't read readmes. 2. A lot of people are too dumb to be able to install Xvfb apparently. 3. Because the exception complains about mismatched architecture, I get a lot of people insisting that I've f**ked up and that I need to do a 64bit / 32bit build. 4. A lot of people go "it doesn't work, you suck" and never come back. |
|
|
|
|
DzzD
|
|
«
Reply #19 - Posted
2010-12-22 11:54:55 » |
|
I did a try and think it should/may work (@riven : too bad I cant embed the Applet in this post :p) : cube is rotated but edge (right & left) are still vertical
Click to run AppletCube size : 1*1*1 unit Camera FOV : 0.002° Distance between cube an camera : 2000000 units |
|
|
|
|
Orangy Tang
|
|
«
Reply #20 - Posted
2010-12-22 12:04:06 » |
|
Interesting! Any chance you could switch in an actual ortho projection to compare?
|
|
|
|
|
DzzD
|
|
«
Reply #21 - Posted
2010-12-22 12:07:49 » |
|
Interesting! Any chance you could switch in an actual ortho projection to compare?
I will try to render both on 3DS max to see the difference |
|
|
|
|
DzzD
|
|
«
Reply #22 - Posted
2010-12-22 21:03:49 » |
|
Perspective rendering 3D Studio Max 10 Orthodromic rendering 3D Studio Max 10 Perspective rendering 3DzzD No real difference : only a little scale between perspective & Orthodromic but that becasue I was not able to easily set exact same zoom for orthodromic rendering & perspective rendering on max EDIT: How much error are we talking about? Because I'm looking at the Processing texture example and there's some warpage of the texture in a perspective view, so I guess they're not doing perspective correct mapping, but what's the error like the other way? yes this is a faked texture mapping, you can easily see error already but it will be even more noticable if you try to render a grid |
|
|
|
|
princec
|
|
«
Reply #23 - Posted
2010-12-23 13:47:08 » |
|
I'm missing something: why software renderer?
Because now I've ironed out all the big bugs for Tectonicus, the number one "bug" report is people trying to use it on headless server boxes which don't have an opengl-capable graphics card. Hence a software renderer as well as a hardware renderer (even if it is a bit slower) is on my todo list, if it can be done without too much effort. Processing looks like the best option at the moment, even it it does use a totally different API. did xvfb with mesa not work? It does, but: 1. I'm tired of getting "bug" reports and having to say "install Xvfb" all the time. People don't read readmes. 2. A lot of people are too dumb to be able to install Xvfb apparently. 3. Because the exception complains about mismatched architecture, I get a lot of people insisting that I've f**ked up and that I need to do a 64bit / 32bit build. 4. A lot of people go "it doesn't work, you suck" and never come back. 1. Whatever way they have to contact you, make sure that they simply get an automated reply that says "install xvfb". 2. Ignore these people. 3. Catch the exception and rethrow it saying "install xvfb". 4. Ignore these people. I am being serious btw. Cas  |
|
|
|
|
deepthought
|
|
«
Reply #24 - Posted
2010-12-29 21:53:23 » |
|
hey i've got 2 questions: is it possible to bypass the scene graph in 3dzzd?(i don't like scenegraphs. i just prefer to use opengl immediate mode or vertex arrays), or is it possible to use vertex arrays in processing 3d.
@orangyTang I think irrlicht has a software renderer. there might be a way to just use it by itself.
|
|
|
|
|
gouessej
|
|
«
Reply #25 - Posted
2011-01-04 13:49:01 » |
|
i don't like scenegraphs
What is wrong with scenegraphs? OpenGL immediate mode is slow and has been removed from OpenGL ES. When used correctly, scenegraphs allow to get better performance than a naive use of vertex arrays. |
|
|
|
|
Roquen
|
|
«
Reply #26 - Posted
2011-01-04 13:56:30 » |
|
Scenegraphs are a really poor design model for games. The list a reasons is pretty long and covered in literature.
|
|
|
|
|
|
Eli Delventhal
|
|
«
Reply #27 - Posted
2011-01-04 19:27:36 » |
|
i don't like scenegraphs
What is wrong with scenegraphs? OpenGL immediate mode is slow and has been removed from OpenGL ES. When used correctly, scenegraphs allow to get better performance than a naive use of vertex arrays. I typically don't use a scenegraph because I can more specifically optimize the rendering path to match my game without one. And when there are a lot of entities popping in and out managing this in a scenegraph gets annoying. |
|
|
|
|
princec
|
|
«
Reply #28 - Posted
2011-01-04 20:39:33 » |
|
I disagree, on the principle that there are many many different types of scenegraph and that nearly all modern games use one. Eg. Unreal Engine, idtech5, Quake, etc. They are all scenegraphs. They are just nothing like Java3D, which is probably what gives you sweaty nightmares at night. <edit>Even Revenge of the Titans uses a scenegraph. Cas |
|
|
|
|
Roquen
|
|
«
Reply #29 - Posted
2011-01-04 21:00:26 » |
|
A scenegraph is a specific type of data structure. None of the game mentioned use a scenegraph.
|
|
|
|
|
|
