Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (780)
Games in Android Showcase (233)
games submitted by our members
Games in WIP (857)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / Xith3D Forums / Re: Help me implementing PS and VS shaders on: 2004-01-24 20:34:24
I sometimes have similar, incidental & strange, compilation errors but in my JBuilder environment.
Exiting JBuilder, then deleting the project's classes directory, and forcing a complete recompile has always
solved these errors for me.

2  Java Game APIs & Engines / Xith3D Forums / Re: Picking enhancement on: 2003-11-22 20:55:14
Thanks for your explanation Yuri; I can see why you'd prefer the picking not to clutter
up the rendering thread.
My particular interest is volume (simply outer hull) and cross-section visualization of lots of
cells, where, after having created the shapes for rendering, the only connection back to the
underlying data structures is really only the index of each primitive in the shape's
geometry array.
Based on a pick result intersection point, and/or closest vertex alone it is very
clumsy and time-consuming to determine the exact primitive by doing all sorts of 'isInside'
tests Sad
Will the programmatic picking you guys are developing support giving back the primitive
index in the pick result? Would solve all my picking issues, and actually there'd
be no need to bother the renderer with custom pick names.

Remains possible gl picking support for DIY jogl drawing in future shape predraw hooks.
It may still be a good idea to alter PickRenderResult as mentioned above, so
to contain a single Node + the pick names, minus the one used for node id.
I like the idea of toying will jogl knowing that the bulk of the transforms is dealt with by
the scene graph.

3  Java Game APIs & Engines / Xith3D Forums / Picking enhancement on: 2003-11-22 12:16:13


I've been tracking/toying with Xith for some time now,
and like it a lot.
I would like to propose to enhance Xith3D picking somewhat.

Currently Xith3D uses the standard OpenGL picking mechanism with a select buffer,
and picking by Node.
PickRenderResult.getNodes() lists the (I think: single) Node picked
and a zmin, zmax value.

This use of OpenGL picking is quite specific to picking Node's and:
- does not allow identification of primitives (which quad of the
 immense quadarray has been picked?)
- does not allow the application to provide (multiple) pick names
 (the cell picked has this cellId, this segmentId, this clusterId etc.
  Admittedly I haven't seen a number of identification codes > 3,
  and we packed them into a single int. Works, but caused a bit of a range
  limitation )
- any future node predraw hooks for DIY OpenGL drawing cannot get
 custom pick results back.

The proposal below attempts to remedy this and keep on using standard OpenGL picking.

- add to Node:
 // when true, the first name on the stack will be the primitive index.
 // this allows getting (close) to the picked coordinates, for applications that do
 // not want to deal with custom names.
 <not thought through>
 // geoArray.getValidVertexCount()/# vertices_per_primitive for normal geometry
 // igeoArray.getValidIndexCount()/# vertices_per_primitive for indexed geometry ???
 </not thought through>
 boolean pickPrimitiveIndex = false;

 // the number of names that this node can use for identifying its pick result
 // value 0 means that only the default node picking is available.
 int customNameStackDepth = 0;

- change PickRenderResult
 private Node node;       // should be just one Node + all of its sub-identification,
 private int[] names;     // so complete contents of name stack at pick time - 1
                          // (the name used to identify the node itself)

- to allow multiple custom names per primitive of a Node, add to GeomContainer
 // array of size nameStackDepth, containing the pick names per primitive
 <not thought through>
 // the pickNames could be java int arrays, subject to GC
 </not thought through>
 GeomDataInterface[] pickNames;

- add GeomNioIntData (similar to GeomNioFloatData) for use as pickNames

The biggest change is with rendering: with custom names per primitive, we can't use
glDrawArrays or glDrawElements for drawing.
When in pick mode && custom picking is enabled, drawing needs to revert to drawing
per primitive:
- if (pickPrimitiveIndex) push current primitive index
- push all custom (customNameStackDepth) names on the stack
- draw primitive, using the appropriate glArrayElement() call
- pop all custom names off the stack
- if (pickPrimitiveIndex) pop

Thus, ShapeAtomPeer needs to be aware of the pickMode.
Additionally proper checking of the pickNames data should be done,
customNameStackDepth + #internal names should be checked to be < GL_NAME_STACK_DEPTH,
(allthough this is not likely to be a problem as GL_NAME_STACK_DEPTH >= 64 ...)
convertSelectBuffer would need to be changed etc...
But in the end this would provide a very flexible (configurable per Node) picking mechanism.

What do you think?
Does this conflict with other developments in the pipeline?

Pages: [1]
hadezbladez (739 views)
2018-11-16 13:46:03

hadezbladez (379 views)
2018-11-16 13:41:33

hadezbladez (729 views)
2018-11-16 13:35:35

hadezbladez (191 views)
2018-11-16 13:32:03

EgonOlsen (2388 views)
2018-06-10 19:43:48

EgonOlsen (2550 views)
2018-06-10 19:43:44

EgonOlsen (1477 views)
2018-06-10 19:43:20

DesertCoockie (2141 views)
2018-05-13 18:23:11

nelsongames (1945 views)
2018-04-24 18:15:36

nelsongames (2624 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!