Discussion:
Recent developments in Qt/3D
(too old to reply)
Rhys Weatherley
2010-10-20 03:02:10 UTC
Permalink
There have been a lot of changes to Qt/3D over the last month, so I thought
I'd send out a quick summary.

- "Viewport" in QML/3D will do QGLView-style navigation even when the QML
application is run with qmlviewer. DefaultNavigator is no longer required.
It is still possible to override the built-in navigation with an explicit
MouseArea if you want to do your own thing. The major remaining difference
between qml3d and qmlviewer is support for stereo rendering - once we can do
stereo in qmlviewer, qml3d will be retired.

- If the user forgets to supply "-opengl" or "-graphicssystem opengl" to
qmlviewer, then "Viewport" will force the QDeclarativeView to use a QGLWidget
as the viewport.

- 3D mice that report 6 degrees of freedom are now supported under Linux and
Windows (Mac is TBD), with modelviewer modified to show how to use them.
More information here:

http://doc.qt.nokia.com/qt3d-snapshot/qt3d-3dmouse.html

- QGLShaderProgramEffect has had a significant overhaul, making it a much
nicer class for integrating shaders into your Qt/3D application. Most of the
logic that used to be needed in update() and setActive() is now done for you.
See the shader examples in pageflip and teaservice.

- QGLAbstractEffect::setVertexAttribute() has been removed. QGLPainter will
set the vertex attributes on the correct GL attribute indexes. This makes it
easier to use the same vertex buffer with multiple effects without needing to
reestablish the vertex state every time the effect is changed.

- QGLCylinder class added to threed/geometry.

- Refinements to the mathematical classes under threed/math3d: QRay3D, QBox3D,
QPlane3D, QTriangle3D, and QSphere3D.

- QGLCameraAnimation class, for automatically animating from one [eye, center,
upVector] camera location to another along the shortest rotation path. Use
modelviewer's "Top View", "Left View", etc options to see it in action.

- We're working on removing the private API dependencies so that Qt/3D can
compile against a standard Qt SDK. Not quite there yet, but making progress.

More changes are on the way as we refine the API's and stablise Qt/3D for
release in parallel with Qt 4.8 early next year.

Cheers,

Rhys.
Robinson, David
2010-10-21 17:52:09 UTC
Permalink
Having read the news, I pull'd the latest Git changes & cleaned my aging
Git repo & rebuilt.

My WinXP SP3 Win SDK 7.1 build gets stuck quiet early on as follows:

debug\moc_qglext_p.cpp(44) : warning C4273: 'staticMetaObject' :
inconsistent dll linkage
c:\qt\qt3d\threed\debug\../enablers/qglext_p.h(192) : see
previous definition of 'public: static QMetaObject const
QGLSignalProxy::staticMetaObject'
debug\moc_qglext_p.cpp(44) : error C2491:
'QGLSignalProxy::staticMetaObject' : definition of dllimport static data
member not allowed

Not seen this before. Still building off a Qt source Git repo. Can
anyone help?

Regards
David Robinson

-----Original Message-----
From: qt-3d-bounces-Ihz76zOu8S21Z/+***@public.gmane.org [mailto:qt-3d-bounces-Ihz76zOu8S21Z/+***@public.gmane.org]
On Behalf Of Rhys Weatherley
Sent: 20 October 2010 04:02
To: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
Subject: [Qt-3d] Recent developments in Qt/3D

There have been a lot of changes to Qt/3D over the last month, so I
thought
I'd send out a quick summary.

- "Viewport" in QML/3D will do QGLView-style navigation even when the
QML
application is run with qmlviewer. DefaultNavigator is no longer
required.
It is still possible to override the built-in navigation with an
explicit
MouseArea if you want to do your own thing. The major remaining
difference
between qml3d and qmlviewer is support for stereo rendering - once we
can do
stereo in qmlviewer, qml3d will be retired.

- If the user forgets to supply "-opengl" or "-graphicssystem opengl" to

qmlviewer, then "Viewport" will force the QDeclarativeView to use a
QGLWidget
as the viewport.

- 3D mice that report 6 degrees of freedom are now supported under Linux
and
Windows (Mac is TBD), with modelviewer modified to show how to use them.

More information here:

http://doc.qt.nokia.com/qt3d-snapshot/qt3d-3dmouse.html

- QGLShaderProgramEffect has had a significant overhaul, making it a
much
nicer class for integrating shaders into your Qt/3D application. Most
of the
logic that used to be needed in update() and setActive() is now done for
you.
See the shader examples in pageflip and teaservice.

- QGLAbstractEffect::setVertexAttribute() has been removed. QGLPainter
will
set the vertex attributes on the correct GL attribute indexes. This
makes it
easier to use the same vertex buffer with multiple effects without
needing to
reestablish the vertex state every time the effect is changed.

- QGLCylinder class added to threed/geometry.

- Refinements to the mathematical classes under threed/math3d: QRay3D,
QBox3D,
QPlane3D, QTriangle3D, and QSphere3D.

- QGLCameraAnimation class, for automatically animating from one [eye,
center,
upVector] camera location to another along the shortest rotation path.
Use
modelviewer's "Top View", "Left View", etc options to see it in action.

- We're working on removing the private API dependencies so that Qt/3D
can
compile against a standard Qt SDK. Not quite there yet, but making
progress.

More changes are on the way as we refine the API's and stablise Qt/3D
for
release in parallel with Qt 4.8 early next year.

Cheers,

Rhys.
_______________________________________________
Qt-3d mailing list
Qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
http://lists.trolltech.com/mailman/listinfo/qt-3d


Scanned for viruses by Mimecast.


Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast.
r***@public.gmane.org
2010-10-21 19:32:05 UTC
Permalink
My bad - it should be fixed now.

Cheers,

Rhys.
________________________________________
From: ext Robinson, David [David.Robinson-***@public.gmane.org]
Sent: Friday, October 22, 2010 3:52 AM
To: Weatherley Rhys (Nokia-MS-Qt/Brisbane); qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
Subject: RE: [Qt-3d] Recent developments in Qt/3D

Having read the news, I pull'd the latest Git changes & cleaned my aging
Git repo & rebuilt.

My WinXP SP3 Win SDK 7.1 build gets stuck quiet early on as follows:

debug\moc_qglext_p.cpp(44) : warning C4273: 'staticMetaObject' :
inconsistent dll linkage
c:\qt\qt3d\threed\debug\../enablers/qglext_p.h(192) : see
previous definition of 'public: static QMetaObject const
QGLSignalProxy::staticMetaObject'
debug\moc_qglext_p.cpp(44) : error C2491:
'QGLSignalProxy::staticMetaObject' : definition of dllimport static data
member not allowed

Not seen this before. Still building off a Qt source Git repo. Can
anyone help?

Regards
David Robinson

-----Original Message-----
From: qt-3d-bounces-Ihz76zOu8S21Z/+***@public.gmane.org [mailto:qt-3d-bounces-Ihz76zOu8S21Z/+***@public.gmane.org]
On Behalf Of Rhys Weatherley
Sent: 20 October 2010 04:02
To: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
Subject: [Qt-3d] Recent developments in Qt/3D

There have been a lot of changes to Qt/3D over the last month, so I
thought
I'd send out a quick summary.

- "Viewport" in QML/3D will do QGLView-style navigation even when the
QML
application is run with qmlviewer. DefaultNavigator is no longer
required.
It is still possible to override the built-in navigation with an
explicit
MouseArea if you want to do your own thing. The major remaining
difference
between qml3d and qmlviewer is support for stereo rendering - once we
can do
stereo in qmlviewer, qml3d will be retired.

- If the user forgets to supply "-opengl" or "-graphicssystem opengl" to

qmlviewer, then "Viewport" will force the QDeclarativeView to use a
QGLWidget
as the viewport.

- 3D mice that report 6 degrees of freedom are now supported under Linux
and
Windows (Mac is TBD), with modelviewer modified to show how to use them.

More information here:

http://doc.qt.nokia.com/qt3d-snapshot/qt3d-3dmouse.html

- QGLShaderProgramEffect has had a significant overhaul, making it a
much
nicer class for integrating shaders into your Qt/3D application. Most
of the
logic that used to be needed in update() and setActive() is now done for
you.
See the shader examples in pageflip and teaservice.

- QGLAbstractEffect::setVertexAttribute() has been removed. QGLPainter
will
set the vertex attributes on the correct GL attribute indexes. This
makes it
easier to use the same vertex buffer with multiple effects without
needing to
reestablish the vertex state every time the effect is changed.

- QGLCylinder class added to threed/geometry.

- Refinements to the mathematical classes under threed/math3d: QRay3D,
QBox3D,
QPlane3D, QTriangle3D, and QSphere3D.

- QGLCameraAnimation class, for automatically animating from one [eye,
center,
upVector] camera location to another along the shortest rotation path.
Use
modelviewer's "Top View", "Left View", etc options to see it in action.

- We're working on removing the private API dependencies so that Qt/3D
can
compile against a standard Qt SDK. Not quite there yet, but making
progress.

More changes are on the way as we refine the API's and stablise Qt/3D
for
release in parallel with Qt 4.8 early next year.

Cheers,

Rhys.
_______________________________________________
Qt-3d mailing list
Qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
http://lists.trolltech.com/mailman/listinfo/qt-3d


Scanned for viruses by Mimecast.


Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast.
Robinson, David
2010-11-01 11:38:03 UTC
Permalink
Hi Rhys,
Regarding the Viewport & qmlviewer vs qml3d. I still cannot get explicit
MouseAreas to work with qmlviewer when I'm using a viewport.

This makes it really hard to mix 2D & 3D qml. Have you go a working
qmlviewer based example?

Also even when my 2D element has a z: stacking order the Viewport is
drawn over the top. Is there any way to control this?

When recording frames using 'qmlviewer' the viewport is not captured, so
an empty image sequence is generated.

I was going to attach a morphing item3d movie but with the above issue I
could only manage an image grab instead.

I now have a Qml 'MorphItem3D' element as previously discussed; however
it looks more like an exploding Item3d. I can morph vertices no problem
but the textures are a problem as they cannot be derived using mix in
the shaderprogram.

This is no surprise as the tex coords are changing non linearly with
respect to vertices. I see no alternative but to calculate them on the
fly in the shaderprogram, but this could be expensive & access to other
vertices in the cell could be a problem especially in the generic sense.

Can you see any other approach to correct the textures during the morph
to hold the surface together?

Regards
David Robinson


-----Original Message-----
From: qt-3d-bounces-Ihz76zOu8S21Z/+***@public.gmane.org [mailto:qt-3d-bounces-Ihz76zOu8S21Z/+***@public.gmane.org]
On Behalf Of Rhys Weatherley
Sent: 20 October 2010 04:02
To: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
Subject: [Qt-3d] Recent developments in Qt/3D

There have been a lot of changes to Qt/3D over the last month, so I
thought
I'd send out a quick summary.

- "Viewport" in QML/3D will do QGLView-style navigation even when the
QML
application is run with qmlviewer. DefaultNavigator is no longer
required.
It is still possible to override the built-in navigation with an
explicit
MouseArea if you want to do your own thing. The major remaining
difference
between qml3d and qmlviewer is support for stereo rendering - once we
can do
stereo in qmlviewer, qml3d will be retired.

- If the user forgets to supply "-opengl" or "-graphicssystem opengl" to

qmlviewer, then "Viewport" will force the QDeclarativeView to use a
QGLWidget
as the viewport.

- 3D mice that report 6 degrees of freedom are now supported under Linux
and
Windows (Mac is TBD), with modelviewer modified to show how to use them.

More information here:

http://doc.qt.nokia.com/qt3d-snapshot/qt3d-3dmouse.html

- QGLShaderProgramEffect has had a significant overhaul, making it a
much
nicer class for integrating shaders into your Qt/3D application. Most
of the
logic that used to be needed in update() and setActive() is now done for
you.
See the shader examples in pageflip and teaservice.

- QGLAbstractEffect::setVertexAttribute() has been removed. QGLPainter
will
set the vertex attributes on the correct GL attribute indexes. This
makes it
easier to use the same vertex buffer with multiple effects without
needing to
reestablish the vertex state every time the effect is changed.

- QGLCylinder class added to threed/geometry.

- Refinements to the mathematical classes under threed/math3d: QRay3D,
QBox3D,
QPlane3D, QTriangle3D, and QSphere3D.

- QGLCameraAnimation class, for automatically animating from one [eye,
center,
upVector] camera location to another along the shortest rotation path.
Use
modelviewer's "Top View", "Left View", etc options to see it in action.

- We're working on removing the private API dependencies so that Qt/3D
can
compile against a standard Qt SDK. Not quite there yet, but making
progress.

More changes are on the way as we refine the API's and stablise Qt/3D
for
release in parallel with Qt 4.8 early next year.

Cheers,

Rhys.
_______________________________________________
Qt-3d mailing list
Qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
http://lists.trolltech.com/mailman/listinfo/qt-3d


Scanned for viruses by Mimecast.


Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast.
s***@public.gmane.org
2010-11-01 18:00:49 UTC
Permalink
Hi David,

I'd be interested to see how your code is working.

I have been thinking about implementing basic key-framed animations, and I assume morph targets (which is something used as a name for these types of key frame meshes) is a similar problem.

However from what I have seen these are implemented with a strict requirement that the morph and the original vertices have a one to one mapping and have the same indexing, adjacency etc. Its just their position in space that changes.

Given that that is the case, would not your texture co-ordinates remain the same? Surely the st values would remain pinned to the same logical vertex as the vertex value is interpolated from vert to the morph in the shader? Or maybe I'm missing something.

I'm interested to know what the case is for changing the texture coordinate in this way.

I don't have anything useful to say about the 3d/2d qml issues sorry. :-)

________________________________________
From: qt-3d-bounces-Ihz76zOu8S21Z/+***@public.gmane.org [qt-3d-bounces-Ihz76zOu8S21Z/+***@public.gmane.org] On Behalf Of ext Robinson, David [David.Robinson-***@public.gmane.org]
Sent: Monday, November 01, 2010 9:38 PM
To: Weatherley Rhys (Nokia-MS-Qt/Brisbane); qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
Subject: Re: [Qt-3d] Recent developments in Qt/3D

Hi Rhys,
Regarding the Viewport & qmlviewer vs qml3d. I still cannot get explicit
MouseAreas to work with qmlviewer when I'm using a viewport.

This makes it really hard to mix 2D & 3D qml. Have you go a working
qmlviewer based example?

Also even when my 2D element has a z: stacking order the Viewport is
drawn over the top. Is there any way to control this?

When recording frames using 'qmlviewer' the viewport is not captured, so
an empty image sequence is generated.

I was going to attach a morphing item3d movie but with the above issue I
could only manage an image grab instead.

I now have a Qml 'MorphItem3D' element as previously discussed; however
it looks more like an exploding Item3d. I can morph vertices no problem
but the textures are a problem as they cannot be derived using mix in
the shaderprogram.

This is no surprise as the tex coords are changing non linearly with
respect to vertices. I see no alternative but to calculate them on the
fly in the shaderprogram, but this could be expensive & access to other
vertices in the cell could be a problem especially in the generic sense.

Can you see any other approach to correct the textures during the morph
to hold the surface together?

Regards
David Robinson


-----Original Message-----
From: qt-3d-bounces-Ihz76zOu8S21Z/+***@public.gmane.org [mailto:qt-3d-bounces-Ihz76zOu8S21Z/+***@public.gmane.org]
On Behalf Of Rhys Weatherley
Sent: 20 October 2010 04:02
To: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
Subject: [Qt-3d] Recent developments in Qt/3D

There have been a lot of changes to Qt/3D over the last month, so I
thought
I'd send out a quick summary.

- "Viewport" in QML/3D will do QGLView-style navigation even when the
QML
application is run with qmlviewer. DefaultNavigator is no longer
required.
It is still possible to override the built-in navigation with an
explicit
MouseArea if you want to do your own thing. The major remaining
difference
between qml3d and qmlviewer is support for stereo rendering - once we
can do
stereo in qmlviewer, qml3d will be retired.

- If the user forgets to supply "-opengl" or "-graphicssystem opengl" to

qmlviewer, then "Viewport" will force the QDeclarativeView to use a
QGLWidget
as the viewport.

- 3D mice that report 6 degrees of freedom are now supported under Linux
and
Windows (Mac is TBD), with modelviewer modified to show how to use them.

More information here:

http://doc.qt.nokia.com/qt3d-snapshot/qt3d-3dmouse.html

- QGLShaderProgramEffect has had a significant overhaul, making it a
much
nicer class for integrating shaders into your Qt/3D application. Most
of the
logic that used to be needed in update() and setActive() is now done for
you.
See the shader examples in pageflip and teaservice.

- QGLAbstractEffect::setVertexAttribute() has been removed. QGLPainter
will
set the vertex attributes on the correct GL attribute indexes. This
makes it
easier to use the same vertex buffer with multiple effects without
needing to
reestablish the vertex state every time the effect is changed.

- QGLCylinder class added to threed/geometry.

- Refinements to the mathematical classes under threed/math3d: QRay3D,
QBox3D,
QPlane3D, QTriangle3D, and QSphere3D.

- QGLCameraAnimation class, for automatically animating from one [eye,
center,
upVector] camera location to another along the shortest rotation path.
Use
modelviewer's "Top View", "Left View", etc options to see it in action.

- We're working on removing the private API dependencies so that Qt/3D
can
compile against a standard Qt SDK. Not quite there yet, but making
progress.

More changes are on the way as we refine the API's and stablise Qt/3D
for
release in parallel with Qt 4.8 early next year.

Cheers,

Rhys.
_______________________________________________
Qt-3d mailing list
Qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
http://lists.trolltech.com/mailman/listinfo/qt-3d


Scanned for viruses by Mimecast.


Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast.
Robinson, David
2010-11-12 10:49:27 UTC
Permalink
Hi Sarah / Rhys,

As you know I'm writing a MorphItem3D QML class for Qt3D to allow simple
surfaces & shapes to transform using a ShaderProgram element. This
component is working but I'm finding that the strict one to one mapping
of vertices required is broken.



For example I have a simple sequence of mesh grids made up of 37 x 7
(259) data points. I export these to obj files which are imported into
Qt3D meshes. When I output the QGeometryData vertices (as an attribute)
I find not 259 but 1296 vertices have been created!



Where are all these additional vertices coming from?



Then in the animation sequence I try to morph first to one mesh then
another etc. Some meshes have 1296 & some 1294 vertices for example.
This breaks the strict mapping required to mix the vertices in the
ShaderProgram. If I increase the dataset this mismatch gets worse.



My intention here is to show a varying 3D dataset on a timeline. I am
not comfortable with vertex interpolation that is beyond the original
dataset particularly when I have no control over it. Is there any way to
control the creation of these additional vertices (stick explicitly to
the defined data set) or can I govern the mesh to at least use the same
number in each?



Regards

David Robinson




Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast.
s***@public.gmane.org
2010-11-14 23:58:25 UTC
Permalink
Hi David,

That sounds a bit wacky indeed.

Can you send us the code and your .obj files? If this is a bug its a bad one and I should get onto fixing it straight away.

We should not be seeing a lot of extra vertices.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 12/11/2010, at 8:49 PM, ext Robinson, David wrote:

Hi Sarah / Rhys,
As you know I’m writing a MorphItem3D QML class for Qt3D to allow simple surfaces & shapes to transform using a ShaderProgram element. This component is working but I’m finding that the strict one to one mapping of vertices required is broken.

For example I have a simple sequence of mesh grids made up of 37 x 7 (259) data points. I export these to obj files which are imported into Qt3D meshes. When I output the QGeometryData vertices (as an attribute) I find not 259 but 1296 vertices have been created!

Where are all these additional vertices coming from?

Then in the animation sequence I try to morph first to one mesh then another etc. Some meshes have 1296 & some 1294 vertices for example. This breaks the strict mapping required to mix the vertices in the ShaderProgram. If I increase the dataset this mismatch gets worse.

My intention here is to show a varying 3D dataset on a timeline. I am not comfortable with vertex interpolation that is beyond the original dataset particularly when I have no control over it. Is there any way to control the creation of these additional vertices (stick explicitly to the defined data set) or can I govern the mesh to at least use the same number in each?

Regards
David Robinson




Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk>.
Robinson, David
2010-11-26 10:25:47 UTC
Permalink
Hi Sarah,

Have you had a chance to look into this duplicate vertex problem with
obj file imports?

If necessary, were you able to build the source modifications I
provided?



Regards

David Robinson

________________________________

From: Robinson, David
Sent: 17 November 2010 20:14
To: 'sarah.j.smith-***@public.gmane.org'
Cc: rhys.weatherley-***@public.gmane.org
Subject: RE: [Qt-3d] Recent developments in Qt/3D



Hi Sarah,

Please find attached some vertex output from the MorphItem Qml class run
using the 37 x 7 dataset sequence mentioned in my previous email. I
think I've attached all the bits needed including some experimental Qml.
If the mesh import of obj files is where the vertex duplication arises
you won't need to run the qml at all but if you do I'd be interested in
your feedback.



The vertex text files can be compared using a text diff utility & it can
be seen that there are many duplicate vertices in the internal mesh
QGeometryData vertices array for each mesh created from the obj file
import, also attached.



This is perhaps more expensive on storage than necessary but itself does
not lead to mismatched vertex mapping when morphing. What does is the
duplicate vertex no. 363 in the example vertex1296.txt file. Whenever
there are 1296 vertices in the data, which occurs in all sequences bar 1
with 1295, it is this vertex no. 363 that is duplicated.



I should also explain that I have tried this with obj files made up of
Quad & Triangle faces. I originally used quads as this was more natural
for a grid vertex structure. I was thinking that the whole face was
being mapped into the vertex array. Eg 37 x 7 x cyclic vertices per face
(5) = 1295. When the same no. comes out from using triangle faces my
theory is blown over however (37 x 7x 4 x 2 = 2072).



So even when triangle faces are used in the obj's the vertex count comes
out 5 times higher than expected with duplicate adjacent vertices in the
array. Can you please investigate the obj scene format plugin and tell
me if this is a bug or a lack of understanding on my part, many thanks.



Regards

David Robinson

________________________________

From: sarah.j.smith-***@public.gmane.org [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 14 November 2010 23:58
To: Robinson, David
Cc: rhys.weatherley-***@public.gmane.org; qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
Subject: Re: [Qt-3d] Recent developments in Qt/3D



Hi David,



That sounds a bit wacky indeed.



Can you send us the code and your .obj files? If this is a bug its a
bad one and I should get onto fixing it straight away.



We should not be seeing a lot of extra vertices.



Sarah Smith

Senior Engineer

Nokia Qt Development Frameworks

Mobile: +61 448 283 476

sarah.j.smith-***@public.gmane.org







On 12/11/2010, at 8:49 PM, ext Robinson, David wrote:



Hi Sarah / Rhys,

As you know I'm writing a MorphItem3D QML class for Qt3D to allow simple
surfaces & shapes to transform using a ShaderProgram element. This
component is working but I'm finding that the strict one to one mapping
of vertices required is broken.



For example I have a simple sequence of mesh grids made up of 37 x 7
(259) data points. I export these to obj files which are imported into
Qt3D meshes. When I output the QGeometryData vertices (as an attribute)
I find not 259 but 1296 vertices have been created!



Where are all these additional vertices coming from?



Then in the animation sequence I try to morph first to one mesh then
another etc. Some meshes have 1296 & some 1294 vertices for example.
This breaks the strict mapping required to mix the vertices in the
ShaderProgram. If I increase the dataset this mismatch gets worse.



My intention here is to show a varying 3D dataset on a timeline. I am
not comfortable with vertex interpolation that is beyond the original
dataset particularly when I have no control over it. Is there any way to
control the creation of these additional vertices (stick explicitly to
the defined data set) or can I govern the mesh to at least use the same
number in each?



Regards

David Robinson





Please refer to www.anite.com <http://www.anite.com/> for individual
Anite company details. The contents of this e-mail and any attachments
are for the intended recipient only. If you are not the intended
recipient, you are not authorised to and must not disclose, copy,
distribute, or retain this message or any part of it. It may contain
information which is confidential and/or covered by legal professional
or other privilege. Contracts cannot be concluded with us nor legal
service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United
Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast <http://www.mimecast.co.uk> .





Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .


Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast.
s***@public.gmane.org
2010-11-26 11:04:18 UTC
Permalink
Hi David,

Sorry - been a busy week - will look at this on Monday.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 26/11/2010, at 8:25 PM, ext Robinson, David wrote:

Hi Sarah,
Have you had a chance to look into this duplicate vertex problem with obj file imports?
If necessary, were you able to build the source modifications I provided?

Regards
David Robinson
________________________________
From: Robinson, David
Sent: 17 November 2010 20:14
To: 'sarah.j.smith-***@public.gmane.org<mailto:'sarah.j.smith-***@public.gmane.org>'
Cc: rhys.weatherley-***@public.gmane.org<mailto:rhys.weatherley-***@public.gmane.org>
Subject: RE: [Qt-3d] Recent developments in Qt/3D

Hi Sarah,
Please find attached some vertex output from the MorphItem Qml class run using the 37 x 7 dataset sequence mentioned in my previous email. I think I’ve attached all the bits needed including some experimental Qml. If the mesh import of obj files is where the vertex duplication arises you won’t need to run the qml at all but if you do I’d be interested in your feedback.

The vertex text files can be compared using a text diff utility & it can be seen that there are many duplicate vertices in the internal mesh QGeometryData vertices array for each mesh created from the obj file import, also attached.

This is perhaps more expensive on storage than necessary but itself does not lead to mismatched vertex mapping when morphing. What does is the duplicate vertex no. 363 in the example vertex1296.txt file. Whenever there are 1296 vertices in the data, which occurs in all sequences bar 1 with 1295, it is this vertex no. 363 that is duplicated.

I should also explain that I have tried this with obj files made up of Quad & Triangle faces. I originally used quads as this was more natural for a grid vertex structure. I was thinking that the whole face was being mapped into the vertex array. Eg 37 x 7 x cyclic vertices per face (5) = 1295. When the same no. comes out from using triangle faces my theory is blown over however (37 x 7x 4 x 2 = 2072).

So even when triangle faces are used in the obj’s the vertex count comes out 5 times higher than expected with duplicate adjacent vertices in the array. Can you please investigate the obj scene format plugin and tell me if this is a bug or a lack of understanding on my part, many thanks.

Regards
David Robinson
________________________________
From: sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org> [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 14 November 2010 23:58
To: Robinson, David
Cc: rhys.weatherley-***@public.gmane.org<mailto:rhys.weatherley-***@public.gmane.org>; qt-***@trolltech.com<mailto:qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org>
Subject: Re: [Qt-3d] Recent developments in Qt/3D

Hi David,

That sounds a bit wacky indeed.

Can you send us the code and your .obj files? If this is a bug its a bad one and I should get onto fixing it straight away.

We should not be seeing a lot of extra vertices.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 12/11/2010, at 8:49 PM, ext Robinson, David wrote:

Hi Sarah / Rhys,
As you know I’m writing a MorphItem3D QML class for Qt3D to allow simple surfaces & shapes to transform using a ShaderProgram element. This component is working but I’m finding that the strict one to one mapping of vertices required is broken.

For example I have a simple sequence of mesh grids made up of 37 x 7 (259) data points. I export these to obj files which are imported into Qt3D meshes. When I output the QGeometryData vertices (as an attribute) I find not 259 but 1296 vertices have been created!

Where are all these additional vertices coming from?

Then in the animation sequence I try to morph first to one mesh then another etc. Some meshes have 1296 & some 1294 vertices for example. This breaks the strict mapping required to mix the vertices in the ShaderProgram. If I increase the dataset this mismatch gets worse.

My intention here is to show a varying 3D dataset on a timeline. I am not comfortable with vertex interpolation that is beyond the original dataset particularly when I have no control over it. Is there any way to control the creation of these additional vertices (stick explicitly to the defined data set) or can I govern the mesh to at least use the same number in each?

Regards
David Robinson



Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.
s***@public.gmane.org
2010-11-29 08:43:22 UTC
Permalink
By the way - I have written some basic unit tests today for model loading - not committed yet because they are failing.

The idea was that you could achieve the same effect by using the "ForceSmooth" option - which I added to the obj loader as part of this commit - but its not currently passing the unit tests, so you might have to wait for that and just try generating your models with the "s on" option.

That would give you a way of overriding smoothing on obj files from QML.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 26/11/2010, at 9:04 PM, ext sarah.j.smith-***@public.gmane.org<mailto:***@nokia.com> wrote:

Hi David,

Sorry - been a busy week - will look at this on Monday.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 26/11/2010, at 8:25 PM, ext Robinson, David wrote:

Hi Sarah,
Have you had a chance to look into this duplicate vertex problem with obj file imports?
If necessary, were you able to build the source modifications I provided?

Regards
David Robinson
________________________________
From: Robinson, David
Sent: 17 November 2010 20:14
To: 'sarah.j.smith-***@public.gmane.org<mailto:'sarah.j.smith-***@public.gmane.org>'
Cc: rhys.weatherley-***@public.gmane.org<mailto:rhys.weatherley-***@public.gmane.org>
Subject: RE: [Qt-3d] Recent developments in Qt/3D

Hi Sarah,
Please find attached some vertex output from the MorphItem Qml class run using the 37 x 7 dataset sequence mentioned in my previous email. I think I’ve attached all the bits needed including some experimental Qml. If the mesh import of obj files is where the vertex duplication arises you won’t need to run the qml at all but if you do I’d be interested in your feedback.

The vertex text files can be compared using a text diff utility & it can be seen that there are many duplicate vertices in the internal mesh QGeometryData vertices array for each mesh created from the obj file import, also attached.

This is perhaps more expensive on storage than necessary but itself does not lead to mismatched vertex mapping when morphing. What does is the duplicate vertex no. 363 in the example vertex1296.txt file. Whenever there are 1296 vertices in the data, which occurs in all sequences bar 1 with 1295, it is this vertex no. 363 that is duplicated.

I should also explain that I have tried this with obj files made up of Quad & Triangle faces. I originally used quads as this was more natural for a grid vertex structure. I was thinking that the whole face was being mapped into the vertex array. Eg 37 x 7 x cyclic vertices per face (5) = 1295. When the same no. comes out from using triangle faces my theory is blown over however (37 x 7x 4 x 2 = 2072).

So even when triangle faces are used in the obj’s the vertex count comes out 5 times higher than expected with duplicate adjacent vertices in the array. Can you please investigate the obj scene format plugin and tell me if this is a bug or a lack of understanding on my part, many thanks.

Regards
David Robinson
________________________________
From: sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org> [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 14 November 2010 23:58
To: Robinson, David
Cc: rhys.weatherley-***@public.gmane.org<mailto:rhys.weatherley-***@public.gmane.org>; qt-***@trolltech.com<mailto:qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org>
Subject: Re: [Qt-3d] Recent developments in Qt/3D

Hi David,

That sounds a bit wacky indeed.

Can you send us the code and your .obj files? If this is a bug its a bad one and I should get onto fixing it straight away.

We should not be seeing a lot of extra vertices.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 12/11/2010, at 8:49 PM, ext Robinson, David wrote:

Hi Sarah / Rhys,
As you know I’m writing a MorphItem3D QML class for Qt3D to allow simple surfaces & shapes to transform using a ShaderProgram element. This component is working but I’m finding that the strict one to one mapping of vertices required is broken.

For example I have a simple sequence of mesh grids made up of 37 x 7 (259) data points. I export these to obj files which are imported into Qt3D meshes. When I output the QGeometryData vertices (as an attribute) I find not 259 but 1296 vertices have been created!

Where are all these additional vertices coming from?

Then in the animation sequence I try to morph first to one mesh then another etc. Some meshes have 1296 & some 1294 vertices for example. This breaks the strict mapping required to mix the vertices in the ShaderProgram. If I increase the dataset this mismatch gets worse.

My intention here is to show a varying 3D dataset on a timeline. I am not comfortable with vertex interpolation that is beyond the original dataset particularly when I have no control over it. Is there any way to control the creation of these additional vertices (stick explicitly to the defined data set) or can I govern the mesh to at least use the same number in each?

Regards
David Robinson



Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.

<ATT00001..txt>
s***@public.gmane.org
2010-11-29 08:39:07 UTC
Permalink
Hi David,

I have not tried to apply your changes - the structure of the repo has changed a bit just recently.

However my investigations so far point to the problem being that your meshes do not specify smoothing to be turned on.

What this means is that the loader will dup the vertex for every normal incident at the vert, so as to give it the faceted appearance.

Try adding "s on" just before the list of faces.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 26/11/2010, at 8:25 PM, ext Robinson, David wrote:

Hi Sarah,
Have you had a chance to look into this duplicate vertex problem with obj file imports?
If necessary, were you able to build the source modifications I provided?

Regards
David Robinson
________________________________
From: Robinson, David
Sent: 17 November 2010 20:14
To: 'sarah.j.smith-***@public.gmane.org<mailto:'sarah.j.smith-***@public.gmane.org>'
Cc: rhys.weatherley-***@public.gmane.org<mailto:rhys.weatherley-***@public.gmane.org>
Subject: RE: [Qt-3d] Recent developments in Qt/3D

Hi Sarah,
Please find attached some vertex output from the MorphItem Qml class run using the 37 x 7 dataset sequence mentioned in my previous email. I think I’ve attached all the bits needed including some experimental Qml. If the mesh import of obj files is where the vertex duplication arises you won’t need to run the qml at all but if you do I’d be interested in your feedback.

The vertex text files can be compared using a text diff utility & it can be seen that there are many duplicate vertices in the internal mesh QGeometryData vertices array for each mesh created from the obj file import, also attached.

This is perhaps more expensive on storage than necessary but itself does not lead to mismatched vertex mapping when morphing. What does is the duplicate vertex no. 363 in the example vertex1296.txt file. Whenever there are 1296 vertices in the data, which occurs in all sequences bar 1 with 1295, it is this vertex no. 363 that is duplicated.

I should also explain that I have tried this with obj files made up of Quad & Triangle faces. I originally used quads as this was more natural for a grid vertex structure. I was thinking that the whole face was being mapped into the vertex array. Eg 37 x 7 x cyclic vertices per face (5) = 1295. When the same no. comes out from using triangle faces my theory is blown over however (37 x 7x 4 x 2 = 2072).

So even when triangle faces are used in the obj’s the vertex count comes out 5 times higher than expected with duplicate adjacent vertices in the array. Can you please investigate the obj scene format plugin and tell me if this is a bug or a lack of understanding on my part, many thanks.

Regards
David Robinson
________________________________
From: sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org> [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 14 November 2010 23:58
To: Robinson, David
Cc: rhys.weatherley-***@public.gmane.org<mailto:rhys.weatherley-***@public.gmane.org>; qt-***@trolltech.com<mailto:qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org>
Subject: Re: [Qt-3d] Recent developments in Qt/3D

Hi David,

That sounds a bit wacky indeed.

Can you send us the code and your .obj files? If this is a bug its a bad one and I should get onto fixing it straight away.

We should not be seeing a lot of extra vertices.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 12/11/2010, at 8:49 PM, ext Robinson, David wrote:

Hi Sarah / Rhys,
As you know I’m writing a MorphItem3D QML class for Qt3D to allow simple surfaces & shapes to transform using a ShaderProgram element. This component is working but I’m finding that the strict one to one mapping of vertices required is broken.

For example I have a simple sequence of mesh grids made up of 37 x 7 (259) data points. I export these to obj files which are imported into Qt3D meshes. When I output the QGeometryData vertices (as an attribute) I find not 259 but 1296 vertices have been created!

Where are all these additional vertices coming from?

Then in the animation sequence I try to morph first to one mesh then another etc. Some meshes have 1296 & some 1294 vertices for example. This breaks the strict mapping required to mix the vertices in the ShaderProgram. If I increase the dataset this mismatch gets worse.

My intention here is to show a varying 3D dataset on a timeline. I am not comfortable with vertex interpolation that is beyond the original dataset particularly when I have no control over it. Is there any way to control the creation of these additional vertices (stick explicitly to the defined data set) or can I govern the mesh to at least use the same number in each?

Regards
David Robinson



Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.
Robinson, David
2010-11-29 14:03:44 UTC
Permalink
Hi Sarah,

Thanks for you help, I wasn't aware that the obj format I had used which
only included vertices & textures (but no normals) would imply such
normal characteristics, my mistake.



With the surface smoothing ('s on'), I now consistently get 864 vertices
on the quad face obj. While that appears to improve matters I can still
see duplicate vertices in the mesh output. I'm guessing this is made up
of (37 x 7 x 3) + 'Edge effects' (37 + 37 + 7 + 7 - 1).



I can understand the boundaries as some normal data is needed to
constrain the surface here but I don't know why I still get 3 duplicates
for each vert. Does this make sense to you?



Regards

David Robinson

________________________________

From: sarah.j.smith-***@public.gmane.org [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 29 November 2010 08:39
To: Robinson, David
Cc: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org; rhys.weatherley-***@public.gmane.org
Subject: Re: [Qt-3d] Recent developments in Qt/3D



Hi David,



I have not tried to apply your changes - the structure of the repo has
changed a bit just recently.



However my investigations so far point to the problem being that your
meshes do not specify smoothing to be turned on.



What this means is that the loader will dup the vertex for every normal
incident at the vert, so as to give it the faceted appearance.



Try adding "s on" just before the list of faces.



Sarah Smith

Senior Engineer

Nokia Qt Development Frameworks

Mobile: +61 448 283 476

sarah.j.smith-***@public.gmane.org







On 26/11/2010, at 8:25 PM, ext Robinson, David wrote:





Hi Sarah,

Have you had a chance to look into this duplicate vertex problem with
obj file imports?

If necessary, were you able to build the source modifications I
provided?



Regards

David Robinson

________________________________

From: Robinson, David
Sent: 17 November 2010 20:14
To: 'sarah.j.smith-***@public.gmane.org'
Cc: rhys.weatherley-***@public.gmane.org
Subject: RE: [Qt-3d] Recent developments in Qt/3D



Hi Sarah,

Please find attached some vertex output from the MorphItem Qml class run
using the 37 x 7 dataset sequence mentioned in my previous email. I
think I've attached all the bits needed including some experimental Qml.
If the mesh import of obj files is where the vertex duplication arises
you won't need to run the qml at all but if you do I'd be interested in
your feedback.



The vertex text files can be compared using a text diff utility & it can
be seen that there are many duplicate vertices in the internal mesh
QGeometryData vertices array for each mesh created from the obj file
import, also attached.



This is perhaps more expensive on storage than necessary but itself does
not lead to mismatched vertex mapping when morphing. What does is the
duplicate vertex no. 363 in the example vertex1296.txt file. Whenever
there are 1296 vertices in the data, which occurs in all sequences bar 1
with 1295, it is this vertex no. 363 that is duplicated.



I should also explain that I have tried this with obj files made up of
Quad & Triangle faces. I originally used quads as this was more natural
for a grid vertex structure. I was thinking that the whole face was
being mapped into the vertex array. Eg 37 x 7 x cyclic vertices per face
(5) = 1295. When the same no. comes out from using triangle faces my
theory is blown over however (37 x 7x 4 x 2 = 2072).



So even when triangle faces are used in the obj's the vertex count comes
out 5 times higher than expected with duplicate adjacent vertices in the
array. Can you please investigate the obj scene format plugin and tell
me if this is a bug or a lack of understanding on my part, many thanks.



Regards

David Robinson

________________________________

From: sarah.j.smith-***@public.gmane.org [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 14 November 2010 23:58
To: Robinson, David
Cc: rhys.weatherley-***@public.gmane.org; qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
Subject: Re: [Qt-3d] Recent developments in Qt/3D



Hi David,



That sounds a bit wacky indeed.



Can you send us the code and your .obj files? If this is a bug its a
bad one and I should get onto fixing it straight away.



We should not be seeing a lot of extra vertices.



Sarah Smith

Senior Engineer

Nokia Qt Development Frameworks

Mobile: +61 448 283 476

sarah.j.smith-***@public.gmane.org







On 12/11/2010, at 8:49 PM, ext Robinson, David wrote:



Hi Sarah / Rhys,

As you know I'm writing a MorphItem3D QML class for Qt3D to allow simple
surfaces & shapes to transform using a ShaderProgram element. This
component is working but I'm finding that the strict one to one mapping
of vertices required is broken.



For example I have a simple sequence of mesh grids made up of 37 x 7
(259) data points. I export these to obj files which are imported into
Qt3D meshes. When I output the QGeometryData vertices (as an attribute)
I find not 259 but 1296 vertices have been created!



Where are all these additional vertices coming from?



Then in the animation sequence I try to morph first to one mesh then
another etc. Some meshes have 1296 & some 1294 vertices for example.
This breaks the strict mapping required to mix the vertices in the
ShaderProgram. If I increase the dataset this mismatch gets worse.



My intention here is to show a varying 3D dataset on a timeline. I am
not comfortable with vertex interpolation that is beyond the original
dataset particularly when I have no control over it. Is there any way to
control the creation of these additional vertices (stick explicitly to
the defined data set) or can I govern the mesh to at least use the same
number in each?



Regards

David Robinson





Please refer to www.anite.com <http://www.anite.com/> for individual
Anite company details. The contents of this e-mail and any attachments
are for the intended recipient only. If you are not the intended
recipient, you are not authorised to and must not disclose, copy,
distribute, or retain this message or any part of it. It may contain
information which is confidential and/or covered by legal professional
or other privilege. Contracts cannot be concluded with us nor legal
service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United
Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .





Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .



Please refer to www.anite.com <http://www.anite.com/> for individual
Anite company details. The contents of this e-mail and any attachments
are for the intended recipient only. If you are not the intended
recipient, you are not authorised to and must not disclose, copy,
distribute, or retain this message or any part of it. It may contain
information which is confidential and/or covered by legal professional
or other privilege. Contracts cannot be concluded with us nor legal
service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United
Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .





Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .


Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast.
s***@public.gmane.org
2010-11-29 23:49:25 UTC
Permalink
Hi David,

I'll keep going with my testing. The .obj format is very YMMV at present - if I can isolate the problems with the tests and fix them that will improve things.

Watch this space.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 30/11/2010, at 12:03 AM, ext Robinson, David wrote:

Hi Sarah,
Thanks for you help, I wasn’t aware that the obj format I had used which only included vertices & textures (but no normals) would imply such normal characteristics, my mistake.

With the surface smoothing (‘s on’), I now consistently get 864 vertices on the quad face obj. While that appears to improve matters I can still see duplicate vertices in the mesh output. I’m guessing this is made up of (37 x 7 x 3) + ‘Edge effects’ (37 + 37 + 7 + 7 – 1).

I can understand the boundaries as some normal data is needed to constrain the surface here but I don’t know why I still get 3 duplicates for each vert. Does this make sense to you?

Regards
David Robinson
________________________________
From: sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org> [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 29 November 2010 08:39
To: Robinson, David
Cc: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org<mailto:qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org>; ***@nokia.com<mailto:rhys.weatherley-***@public.gmane.org>
Subject: Re: [Qt-3d] Recent developments in Qt/3D

Hi David,

I have not tried to apply your changes - the structure of the repo has changed a bit just recently.

However my investigations so far point to the problem being that your meshes do not specify smoothing to be turned on.

What this means is that the loader will dup the vertex for every normal incident at the vert, so as to give it the faceted appearance.

Try adding "s on" just before the list of faces.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>




On 26/11/2010, at 8:25 PM, ext Robinson, David wrote:


Hi Sarah,
Have you had a chance to look into this duplicate vertex problem with obj file imports?
If necessary, were you able to build the source modifications I provided?

Regards
David Robinson
________________________________
From: Robinson, David
Sent: 17 November 2010 20:14
To: 'sarah.j.smith-***@public.gmane.org<mailto:'sarah.j.smith-***@public.gmane.org>'
Cc: rhys.weatherley-***@public.gmane.org<mailto:rhys.weatherley-***@public.gmane.org>
Subject: RE: [Qt-3d] Recent developments in Qt/3D

Hi Sarah,
Please find attached some vertex output from the MorphItem Qml class run using the 37 x 7 dataset sequence mentioned in my previous email. I think I’ve attached all the bits needed including some experimental Qml. If the mesh import of obj files is where the vertex duplication arises you won’t need to run the qml at all but if you do I’d be interested in your feedback.

The vertex text files can be compared using a text diff utility & it can be seen that there are many duplicate vertices in the internal mesh QGeometryData vertices array for each mesh created from the obj file import, also attached.

This is perhaps more expensive on storage than necessary but itself does not lead to mismatched vertex mapping when morphing. What does is the duplicate vertex no. 363 in the example vertex1296.txt file. Whenever there are 1296 vertices in the data, which occurs in all sequences bar 1 with 1295, it is this vertex no. 363 that is duplicated.

I should also explain that I have tried this with obj files made up of Quad & Triangle faces. I originally used quads as this was more natural for a grid vertex structure. I was thinking that the whole face was being mapped into the vertex array. Eg 37 x 7 x cyclic vertices per face (5) = 1295. When the same no. comes out from using triangle faces my theory is blown over however (37 x 7x 4 x 2 = 2072).

So even when triangle faces are used in the obj’s the vertex count comes out 5 times higher than expected with duplicate adjacent vertices in the array. Can you please investigate the obj scene format plugin and tell me if this is a bug or a lack of understanding on my part, many thanks.

Regards
David Robinson
________________________________
From: sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org> [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 14 November 2010 23:58
To: Robinson, David
Cc: rhys.weatherley-***@public.gmane.org<mailto:rhys.weatherley-***@public.gmane.org>; qt-***@trolltech.com<mailto:qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org>
Subject: Re: [Qt-3d] Recent developments in Qt/3D

Hi David,

That sounds a bit wacky indeed.

Can you send us the code and your .obj files? If this is a bug its a bad one and I should get onto fixing it straight away.

We should not be seeing a lot of extra vertices.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 12/11/2010, at 8:49 PM, ext Robinson, David wrote:

Hi Sarah / Rhys,
As you know I’m writing a MorphItem3D QML class for Qt3D to allow simple surfaces & shapes to transform using a ShaderProgram element. This component is working but I’m finding that the strict one to one mapping of vertices required is broken.

For example I have a simple sequence of mesh grids made up of 37 x 7 (259) data points. I export these to obj files which are imported into Qt3D meshes. When I output the QGeometryData vertices (as an attribute) I find not 259 but 1296 vertices have been created!

Where are all these additional vertices coming from?

Then in the animation sequence I try to morph first to one mesh then another etc. Some meshes have 1296 & some 1294 vertices for example. This breaks the strict mapping required to mix the vertices in the ShaderProgram. If I increase the dataset this mismatch gets worse.

My intention here is to show a varying 3D dataset on a timeline. I am not comfortable with vertex interpolation that is beyond the original dataset particularly when I have no control over it. Is there any way to control the creation of these additional vertices (stick explicitly to the defined data set) or can I govern the mesh to at least use the same number in each?

Regards
David Robinson



Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.


Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.
Robinson, David
2010-11-30 10:29:00 UTC
Permalink
Hi Sarah,

No that's fine & I'll keep going with mine.



Last night I tried moving to the larger datasets 72 x 72 that had
previously given me a varying number of vertices when morphing. With
smoothing on, these now have the same number of vertices throughout.
This is good and means I can now progress but I am getting different
vertex counts for quads & triangles namely:



15696 for triangle faces = (72 x 72 x 3) + (72 x 2)

21024 for quad faces = (72 x 72 x 4) + (72 x 4)



Assuming the extra vertices are due to surface boundaries, it seems the
vertex of each facet normal is still stored resulting is duplicate verts
by a factor that mirrors the number of nodes on the face.



I see from the obj spec that if I list the normals explicitly smoothing
groups are superseded so I'll give this a go.

When the vert counts are so high the model takes too long to load



Regards

David Robinson

________________________________

From: sarah.j.smith-***@public.gmane.org [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 29 November 2010 23:49
To: Robinson, David
Cc: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org; rhys.weatherley-***@public.gmane.org
Subject: Re: [Qt-3d] Recent developments in Qt/3D



Hi David,



I'll keep going with my testing. The .obj format is very YMMV at
present - if I can isolate the problems with the tests and fix them that
will improve things.



Watch this space.



Sarah Smith

Senior Engineer

Nokia Qt Development Frameworks

Mobile: +61 448 283 476

sarah.j.smith-***@public.gmane.org







On 30/11/2010, at 12:03 AM, ext Robinson, David wrote:





Hi Sarah,

Thanks for you help, I wasn't aware that the obj format I had used which
only included vertices & textures (but no normals) would imply such
normal characteristics, my mistake.



With the surface smoothing ('s on'), I now consistently get 864 vertices
on the quad face obj. While that appears to improve matters I can still
see duplicate vertices in the mesh output. I'm guessing this is made up
of (37 x 7 x 3) + 'Edge effects' (37 + 37 + 7 + 7 - 1).



I can understand the boundaries as some normal data is needed to
constrain the surface here but I don't know why I still get 3 duplicates
for each vert. Does this make sense to you?



Regards

David Robinson

________________________________

From: sarah.j.smith-***@public.gmane.org [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 29 November 2010 08:39
To: Robinson, David
Cc: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org; rhys.weatherley-***@public.gmane.org
Subject: Re: [Qt-3d] Recent developments in Qt/3D



Hi David,



I have not tried to apply your changes - the structure of the repo has
changed a bit just recently.



However my investigations so far point to the problem being that your
meshes do not specify smoothing to be turned on.



What this means is that the loader will dup the vertex for every normal
incident at the vert, so as to give it the faceted appearance.



Try adding "s on" just before the list of faces.



Sarah Smith

Senior Engineer

Nokia Qt Development Frameworks

Mobile: +61 448 283 476

sarah.j.smith-***@public.gmane.org









On 26/11/2010, at 8:25 PM, ext Robinson, David wrote:






Hi Sarah,

Have you had a chance to look into this duplicate vertex problem with
obj file imports?

If necessary, were you able to build the source modifications I
provided?



Regards

David Robinson

________________________________

From: Robinson, David
Sent: 17 November 2010 20:14
To: 'sarah.j.smith-***@public.gmane.org'
Cc: rhys.weatherley-***@public.gmane.org
Subject: RE: [Qt-3d] Recent developments in Qt/3D



Hi Sarah,

Please find attached some vertex output from the MorphItem Qml class run
using the 37 x 7 dataset sequence mentioned in my previous email. I
think I've attached all the bits needed including some experimental Qml.
If the mesh import of obj files is where the vertex duplication arises
you won't need to run the qml at all but if you do I'd be interested in
your feedback.



The vertex text files can be compared using a text diff utility & it can
be seen that there are many duplicate vertices in the internal mesh
QGeometryData vertices array for each mesh created from the obj file
import, also attached.



This is perhaps more expensive on storage than necessary but itself does
not lead to mismatched vertex mapping when morphing. What does is the
duplicate vertex no. 363 in the example vertex1296.txt file. Whenever
there are 1296 vertices in the data, which occurs in all sequences bar 1
with 1295, it is this vertex no. 363 that is duplicated.



I should also explain that I have tried this with obj files made up of
Quad & Triangle faces. I originally used quads as this was more natural
for a grid vertex structure. I was thinking that the whole face was
being mapped into the vertex array. Eg 37 x 7 x cyclic vertices per face
(5) = 1295. When the same no. comes out from using triangle faces my
theory is blown over however (37 x 7x 4 x 2 = 2072).



So even when triangle faces are used in the obj's the vertex count comes
out 5 times higher than expected with duplicate adjacent vertices in the
array. Can you please investigate the obj scene format plugin and tell
me if this is a bug or a lack of understanding on my part, many thanks.



Regards

David Robinson

________________________________

From: sarah.j.smith-***@public.gmane.org [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 14 November 2010 23:58
To: Robinson, David
Cc: rhys.weatherley-***@public.gmane.org; qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
Subject: Re: [Qt-3d] Recent developments in Qt/3D



Hi David,



That sounds a bit wacky indeed.



Can you send us the code and your .obj files? If this is a bug its a
bad one and I should get onto fixing it straight away.



We should not be seeing a lot of extra vertices.



Sarah Smith

Senior Engineer

Nokia Qt Development Frameworks

Mobile: +61 448 283 476

sarah.j.smith-***@public.gmane.org







On 12/11/2010, at 8:49 PM, ext Robinson, David wrote:



Hi Sarah / Rhys,

As you know I'm writing a MorphItem3D QML class for Qt3D to allow simple
surfaces & shapes to transform using a ShaderProgram element. This
component is working but I'm finding that the strict one to one mapping
of vertices required is broken.



For example I have a simple sequence of mesh grids made up of 37 x 7
(259) data points. I export these to obj files which are imported into
Qt3D meshes. When I output the QGeometryData vertices (as an attribute)
I find not 259 but 1296 vertices have been created!



Where are all these additional vertices coming from?



Then in the animation sequence I try to morph first to one mesh then
another etc. Some meshes have 1296 & some 1294 vertices for example.
This breaks the strict mapping required to mix the vertices in the
ShaderProgram. If I increase the dataset this mismatch gets worse.



My intention here is to show a varying 3D dataset on a timeline. I am
not comfortable with vertex interpolation that is beyond the original
dataset particularly when I have no control over it. Is there any way to
control the creation of these additional vertices (stick explicitly to
the defined data set) or can I govern the mesh to at least use the same
number in each?



Regards

David Robinson





Please refer to www.anite.com <http://www.anite.com/> for individual
Anite company details. The contents of this e-mail and any attachments
are for the intended recipient only. If you are not the intended
recipient, you are not authorised to and must not disclose, copy,
distribute, or retain this message or any part of it. It may contain
information which is confidential and/or covered by legal professional
or other privilege. Contracts cannot be concluded with us nor legal
service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United
Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .





Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .



Please refer to www.anite.com <http://www.anite.com/> for individual
Anite company details. The contents of this e-mail and any attachments
are for the intended recipient only. If you are not the intended
recipient, you are not authorised to and must not disclose, copy,
distribute, or retain this message or any part of it. It may contain
information which is confidential and/or covered by legal professional
or other privilege. Contracts cannot be concluded with us nor legal
service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United
Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .





Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .



Please refer to www.anite.com <http://www.anite.com/> for individual
Anite company details. The contents of this e-mail and any attachments
are for the intended recipient only. If you are not the intended
recipient, you are not authorised to and must not disclose, copy,
distribute, or retain this message or any part of it. It may contain
information which is confidential and/or covered by legal professional
or other privilege. Contracts cannot be concluded with us nor legal
service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United
Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .





Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .


Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast.
s***@public.gmane.org
2010-11-30 10:53:30 UTC
Permalink
Hi David,

I'm taking some time out to go over this on the list because others might come across the same problem. Event tho' its covered in our doco it can be a bit obtuse to see how it works.

Ok - so there are two problems here -

one is that your file did not have smoothing turned on, and
the second was that specifying texture coordinates (in a way that was unsupported) which was defeating smoothing.

With change c2f154cb67a5c157e7a40f58a40851ed4d6ddd6e you can now specify "ForceSmooth" when loading a model with the obj loader. I have written a few basic unit tests to cover that, and also made some other minor fixes to the loader so it generates node naming a bit more in line with our usage.

But the obj loader was working to spec - albeit perhaps a not very well documented spec.

See this doco:

http://doc.qt.nokia.com/qt3d-snapshot/qglbuilder.html#geometry-data-in-a-section

Here is what happens with smoothing. Say you have a mesh which is a set of row apon row of quad faces - basically a surface divided up into a grid of square faces. This is like your wave obj models. This sort of thing is very common in character modelling and many other types of models too.

In this sort of mesh, each vert is often shared by 6 faces. When you add a quad face, two of the verts are duplicated right away when you divide the quad into two triangles. But there are also duplicates from the neighbouring strips. The loader has to go back through previously added vertices and check to index those, thus storing only one copy of the vert.

Smoothing impacts on this because it is done by taking the normals for each face and averaging it across the mesh - this is done by accumulating each incoming normal at a vertex into a sum, and the renormalizing at the end.

When the mesh is unsmoothed, each different normal at a vertex forces the vertex to retain a copy so it can carry the extra normal information.

To handle this, and to allow smooth shading of these sorts of meshes, here is what happens:

1) Model sends a quad to the builder - the builder calculates a normal vector for the quad if needed
2) That adds two triangles, which means 6 indices, each having the same normal
3) The builder receives the 6 incoming indexed vertices, one after the other, and for each one, tries to coalesce them
4) It looks at previously received vertices and finds ones that are the same - could be in the same quad or from a neighbouring strip
5) if it finds one it will check if it can coalesce them - throwing away the incoming copy and just referencing it with an index
6) the check is done by making sure that information would not be lost - if the new vert copy has unique info it cannot be thrown away
7a) if the mesh is being smoothed, then the normals are absorbed into a sum at each vert (and will not disallow the vert from being coalesced)
7b) if the mesh is being faceted, then the verts have to have their copies retained for each different normal
8) if the mesh has texture coordinates and the same vertex has different tex coords on different indices coalescing cannot happen

The last item 8) is the kicker for you - see the link above for the doco about a texture **seam**.

Other loaders for other 3D software do the same thing.

***@bq-macdev1 ~/depot/research/qt3d: grep '^f ' tests/auto/threed/load_model/models/wave.obj | wc -l
216
***@bq-macdev1 ~/depot/research/qt3d: grep '^v ' tests/auto/threed/load_model/models/wave.obj | wc -l
259

The face commands are quads - with 4 indices.

What this meant was that you got 6 * 216 = 1296 indices. When you had faceted on every face got a different normal and you got 1296 vertices as well.

The next problem was the middle of the file looked like this:

v 180 60 104.229
v 180 120 39.241
v 180 180 20.21
vt 1 0
vt 1 1
vt 0 0
vt 0 1
f 1/1 2/2 9/3 8/4
f 2/1 3/2 10/3 9/4
f 3/1 4/2 11/3 10/4

Here you specify just 4 texture coordinates and map the same ones onto every vertex of the faces. Unfortunately the obj loader does not support texture coordinates like this - so for the last face listed above it would do

f 3/3 4/4 11/11 10/10

What this meant was that you then got every face being unique, so 4 * 216 = 864 vertices.

If you remove those four lines (which didn't seem to get used anyway as you have no materials specified) then you get just 259 vertices. This is at least according to my tests.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 30/11/2010, at 12:03 AM, ext Robinson, David wrote:

Hi Sarah,
Thanks for you help, I wasn’t aware that the obj format I had used which only included vertices & textures (but no normals) would imply such normal characteristics, my mistake.

With the surface smoothing (‘s on’), I now consistently get 864 vertices on the quad face obj. While that appears to improve matters I can still see duplicate vertices in the mesh output. I’m guessing this is made up of (37 x 7 x 3) + ‘Edge effects’ (37 + 37 + 7 + 7 – 1).

I can understand the boundaries as some normal data is needed to constrain the surface here but I don’t know why I still get 3 duplicates for each vert. Does this make sense to you?

Regards
David Robinson
________________________________
From: sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org> [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 29 November 2010 08:39
To: Robinson, David
Cc: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org<mailto:qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org>; ***@nokia.com<mailto:rhys.weatherley-***@public.gmane.org>
Subject: Re: [Qt-3d] Recent developments in Qt/3D

Hi David,

I have not tried to apply your changes - the structure of the repo has changed a bit just recently.

However my investigations so far point to the problem being that your meshes do not specify smoothing to be turned on.

What this means is that the loader will dup the vertex for every normal incident at the vert, so as to give it the faceted appearance.

Try adding "s on" just before the list of faces.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>




On 26/11/2010, at 8:25 PM, ext Robinson, David wrote:


Hi Sarah,
Have you had a chance to look into this duplicate vertex problem with obj file imports?
If necessary, were you able to build the source modifications I provided?

Regards
David Robinson
________________________________
From: Robinson, David
Sent: 17 November 2010 20:14
To: 'sarah.j.smith-***@public.gmane.org<mailto:'sarah.j.smith-***@public.gmane.org>'
Cc: rhys.weatherley-***@public.gmane.org<mailto:rhys.weatherley-***@public.gmane.org>
Subject: RE: [Qt-3d] Recent developments in Qt/3D

Hi Sarah,
Please find attached some vertex output from the MorphItem Qml class run using the 37 x 7 dataset sequence mentioned in my previous email. I think I’ve attached all the bits needed including some experimental Qml. If the mesh import of obj files is where the vertex duplication arises you won’t need to run the qml at all but if you do I’d be interested in your feedback.

The vertex text files can be compared using a text diff utility & it can be seen that there are many duplicate vertices in the internal mesh QGeometryData vertices array for each mesh created from the obj file import, also attached.

This is perhaps more expensive on storage than necessary but itself does not lead to mismatched vertex mapping when morphing. What does is the duplicate vertex no. 363 in the example vertex1296.txt file. Whenever there are 1296 vertices in the data, which occurs in all sequences bar 1 with 1295, it is this vertex no. 363 that is duplicated.

I should also explain that I have tried this with obj files made up of Quad & Triangle faces. I originally used quads as this was more natural for a grid vertex structure. I was thinking that the whole face was being mapped into the vertex array. Eg 37 x 7 x cyclic vertices per face (5) = 1295. When the same no. comes out from using triangle faces my theory is blown over however (37 x 7x 4 x 2 = 2072).

So even when triangle faces are used in the obj’s the vertex count comes out 5 times higher than expected with duplicate adjacent vertices in the array. Can you please investigate the obj scene format plugin and tell me if this is a bug or a lack of understanding on my part, many thanks.

Regards
David Robinson
________________________________
From: sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org> [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 14 November 2010 23:58
To: Robinson, David
Cc: rhys.weatherley-***@public.gmane.org<mailto:rhys.weatherley-***@public.gmane.org>; qt-***@trolltech.com<mailto:qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org>
Subject: Re: [Qt-3d] Recent developments in Qt/3D

Hi David,

That sounds a bit wacky indeed.

Can you send us the code and your .obj files? If this is a bug its a bad one and I should get onto fixing it straight away.

We should not be seeing a lot of extra vertices.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 12/11/2010, at 8:49 PM, ext Robinson, David wrote:

Hi Sarah / Rhys,
As you know I’m writing a MorphItem3D QML class for Qt3D to allow simple surfaces & shapes to transform using a ShaderProgram element. This component is working but I’m finding that the strict one to one mapping of vertices required is broken.

For example I have a simple sequence of mesh grids made up of 37 x 7 (259) data points. I export these to obj files which are imported into Qt3D meshes. When I output the QGeometryData vertices (as an attribute) I find not 259 but 1296 vertices have been created!

Where are all these additional vertices coming from?

Then in the animation sequence I try to morph first to one mesh then another etc. Some meshes have 1296 & some 1294 vertices for example. This breaks the strict mapping required to mix the vertices in the ShaderProgram. If I increase the dataset this mismatch gets worse.

My intention here is to show a varying 3D dataset on a timeline. I am not comfortable with vertex interpolation that is beyond the original dataset particularly when I have no control over it. Is there any way to control the creation of these additional vertices (stick explicitly to the defined data set) or can I govern the mesh to at least use the same number in each?

Regards
David Robinson



Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.


Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.
Robinson, David
2010-11-30 12:00:37 UTC
Permalink
Hi Sarah,

I should explain that originally my dataset and app did not use
textures, instead I apply a colour gradient to the glVertex based on the
y value (this I would still like to do in Qt3D but don't know how?).



I only added this in the obj format output because without textures Qt3D
crashes when importing the obj & using a shader program to morph, even
though the textures are meant to be optional (without them can I still
use a shader program?).



As a result I made up some 'dummy' textures to go with as an interim,
that turns out to be my mistake, thanks for the detailed info, this will
be useful to others I'm sure.



Regards

David Robinson

________________________________

From: sarah.j.smith-***@public.gmane.org [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 30 November 2010 10:54
To: Robinson, David
Cc: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org; rhys.weatherley-***@public.gmane.org
Subject: Re: [Qt-3d] Recent developments in Qt/3D



Hi David,



I'm taking some time out to go over this on the list because others
might come across the same problem. Event tho' its covered in our doco
it can be a bit obtuse to see how it works.



Ok - so there are two problems here -



one is that your file did not have smoothing turned on, and

the second was that specifying texture coordinates (in a way that
was unsupported) which was defeating smoothing.



With change c2f154cb67a5c157e7a40f58a40851ed4d6ddd6e you can now specify
"ForceSmooth" when loading a model with the obj loader. I have written
a few basic unit tests to cover that, and also made some other minor
fixes to the loader so it generates node naming a bit more in line with
our usage.



But the obj loader was working to spec - albeit perhaps a not very well
documented spec.



See this doco:



http://doc.qt.nokia.com/qt3d-snapshot/qglbuilder.html#geometry-data-in-a
-section



Here is what happens with smoothing. Say you have a mesh which is a set
of row apon row of quad faces - basically a surface divided up into a
grid of square faces. This is like your wave obj models. This sort of
thing is very common in character modelling and many other types of
models too.



In this sort of mesh, each vert is often shared by 6 faces. When you
add a quad face, two of the verts are duplicated right away when you
divide the quad into two triangles. But there are also duplicates from
the neighbouring strips. The loader has to go back through previously
added vertices and check to index those, thus storing only one copy of
the vert.



Smoothing impacts on this because it is done by taking the normals for
each face and averaging it across the mesh - this is done by
accumulating each incoming normal at a vertex into a sum, and the
renormalizing at the end.



When the mesh is unsmoothed, each different normal at a vertex forces
the vertex to retain a copy so it can carry the extra normal
information.



To handle this, and to allow smooth shading of these sorts of meshes,
here is what happens:



1) Model sends a quad to the builder - the builder calculates a normal
vector for the quad if needed

2) That adds two triangles, which means 6 indices, each having the same
normal

3) The builder receives the 6 incoming indexed vertices, one after the
other, and for each one, tries to coalesce them

4) It looks at previously received vertices and finds ones that are the
same - could be in the same quad or from a neighbouring strip

5) if it finds one it will check if it can coalesce them - throwing away
the incoming copy and just referencing it with an index

6) the check is done by making sure that information would not be lost -
if the new vert copy has unique info it cannot be thrown away

7a) if the mesh is being smoothed, then the normals are absorbed into a
sum at each vert (and will not disallow the vert from being coalesced)

7b) if the mesh is being faceted, then the verts have to have their
copies retained for each different normal

8) if the mesh has texture coordinates and the same vertex has different
tex coords on different indices coalescing cannot happen



The last item 8) is the kicker for you - see the link above for the doco
about a texture **seam**.



Other loaders for other 3D software do the same thing.



***@bq-macdev1 ~/depot/research/qt3d: grep '^f '
tests/auto/threed/load_model/models/wave.obj | wc -l

216

***@bq-macdev1 ~/depot/research/qt3d: grep '^v '
tests/auto/threed/load_model/models/wave.obj | wc -l

259



The face commands are quads - with 4 indices.



What this meant was that you got 6 * 216 = 1296 indices. When you had
faceted on every face got a different normal and you got 1296 vertices
as well.



The next problem was the middle of the file looked like this:



v 180 60 104.229

v 180 120 39.241

v 180 180 20.21

vt 1 0

vt 1 1

vt 0 0

vt 0 1

f 1/1 2/2 9/3 8/4

f 2/1 3/2 10/3 9/4

f 3/1 4/2 11/3 10/4



Here you specify just 4 texture coordinates and map the same ones onto
every vertex of the faces. Unfortunately the obj loader does not
support texture coordinates like this - so for the last face listed
above it would do



f 3/3 4/4 11/11 10/10



What this meant was that you then got every face being unique, so 4 *
216 = 864 vertices.



If you remove those four lines (which didn't seem to get used anyway as
you have no materials specified) then you get just 259 vertices. This
is at least according to my tests.



Sarah Smith

Senior Engineer

Nokia Qt Development Frameworks

Mobile: +61 448 283 476

sarah.j.smith-***@public.gmane.org







On 30/11/2010, at 12:03 AM, ext Robinson, David wrote:





Hi Sarah,

Thanks for you help, I wasn't aware that the obj format I had used which
only included vertices & textures (but no normals) would imply such
normal characteristics, my mistake.



With the surface smoothing ('s on'), I now consistently get 864 vertices
on the quad face obj. While that appears to improve matters I can still
see duplicate vertices in the mesh output. I'm guessing this is made up
of (37 x 7 x 3) + 'Edge effects' (37 + 37 + 7 + 7 - 1).



I can understand the boundaries as some normal data is needed to
constrain the surface here but I don't know why I still get 3 duplicates
for each vert. Does this make sense to you?



Regards

David Robinson

________________________________

From: sarah.j.smith-***@public.gmane.org [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 29 November 2010 08:39
To: Robinson, David
Cc: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org; rhys.weatherley-***@public.gmane.org
Subject: Re: [Qt-3d] Recent developments in Qt/3D



Hi David,



I have not tried to apply your changes - the structure of the repo has
changed a bit just recently.



However my investigations so far point to the problem being that your
meshes do not specify smoothing to be turned on.



What this means is that the loader will dup the vertex for every normal
incident at the vert, so as to give it the faceted appearance.



Try adding "s on" just before the list of faces.



Sarah Smith

Senior Engineer

Nokia Qt Development Frameworks

Mobile: +61 448 283 476

sarah.j.smith-***@public.gmane.org









On 26/11/2010, at 8:25 PM, ext Robinson, David wrote:






Hi Sarah,

Have you had a chance to look into this duplicate vertex problem with
obj file imports?

If necessary, were you able to build the source modifications I
provided?



Regards

David Robinson

________________________________

From: Robinson, David
Sent: 17 November 2010 20:14
To: 'sarah.j.smith-***@public.gmane.org'
Cc: rhys.weatherley-***@public.gmane.org
Subject: RE: [Qt-3d] Recent developments in Qt/3D



Hi Sarah,

Please find attached some vertex output from the MorphItem Qml class run
using the 37 x 7 dataset sequence mentioned in my previous email. I
think I've attached all the bits needed including some experimental Qml.
If the mesh import of obj files is where the vertex duplication arises
you won't need to run the qml at all but if you do I'd be interested in
your feedback.



The vertex text files can be compared using a text diff utility & it can
be seen that there are many duplicate vertices in the internal mesh
QGeometryData vertices array for each mesh created from the obj file
import, also attached.



This is perhaps more expensive on storage than necessary but itself does
not lead to mismatched vertex mapping when morphing. What does is the
duplicate vertex no. 363 in the example vertex1296.txt file. Whenever
there are 1296 vertices in the data, which occurs in all sequences bar 1
with 1295, it is this vertex no. 363 that is duplicated.



I should also explain that I have tried this with obj files made up of
Quad & Triangle faces. I originally used quads as this was more natural
for a grid vertex structure. I was thinking that the whole face was
being mapped into the vertex array. Eg 37 x 7 x cyclic vertices per face
(5) = 1295. When the same no. comes out from using triangle faces my
theory is blown over however (37 x 7x 4 x 2 = 2072).



So even when triangle faces are used in the obj's the vertex count comes
out 5 times higher than expected with duplicate adjacent vertices in the
array. Can you please investigate the obj scene format plugin and tell
me if this is a bug or a lack of understanding on my part, many thanks.



Regards

David Robinson

________________________________

From: sarah.j.smith-***@public.gmane.org [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 14 November 2010 23:58
To: Robinson, David
Cc: rhys.weatherley-***@public.gmane.org; qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
Subject: Re: [Qt-3d] Recent developments in Qt/3D



Hi David,



That sounds a bit wacky indeed.



Can you send us the code and your .obj files? If this is a bug its a
bad one and I should get onto fixing it straight away.



We should not be seeing a lot of extra vertices.



Sarah Smith

Senior Engineer

Nokia Qt Development Frameworks

Mobile: +61 448 283 476

sarah.j.smith-***@public.gmane.org







On 12/11/2010, at 8:49 PM, ext Robinson, David wrote:



Hi Sarah / Rhys,

As you know I'm writing a MorphItem3D QML class for Qt3D to allow simple
surfaces & shapes to transform using a ShaderProgram element. This
component is working but I'm finding that the strict one to one mapping
of vertices required is broken.



For example I have a simple sequence of mesh grids made up of 37 x 7
(259) data points. I export these to obj files which are imported into
Qt3D meshes. When I output the QGeometryData vertices (as an attribute)
I find not 259 but 1296 vertices have been created!



Where are all these additional vertices coming from?



Then in the animation sequence I try to morph first to one mesh then
another etc. Some meshes have 1296 & some 1294 vertices for example.
This breaks the strict mapping required to mix the vertices in the
ShaderProgram. If I increase the dataset this mismatch gets worse.



My intention here is to show a varying 3D dataset on a timeline. I am
not comfortable with vertex interpolation that is beyond the original
dataset particularly when I have no control over it. Is there any way to
control the creation of these additional vertices (stick explicitly to
the defined data set) or can I govern the mesh to at least use the same
number in each?



Regards

David Robinson





Please refer to www.anite.com <http://www.anite.com/> for individual
Anite company details. The contents of this e-mail and any attachments
are for the intended recipient only. If you are not the intended
recipient, you are not authorised to and must not disclose, copy,
distribute, or retain this message or any part of it. It may contain
information which is confidential and/or covered by legal professional
or other privilege. Contracts cannot be concluded with us nor legal
service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United
Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .





Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .



Please refer to www.anite.com <http://www.anite.com/> for individual
Anite company details. The contents of this e-mail and any attachments
are for the intended recipient only. If you are not the intended
recipient, you are not authorised to and must not disclose, copy,
distribute, or retain this message or any part of it. It may contain
information which is confidential and/or covered by legal professional
or other privilege. Contracts cannot be concluded with us nor legal
service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United
Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .





Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .



Please refer to www.anite.com <http://www.anite.com/> for individual
Anite company details. The contents of this e-mail and any attachments
are for the intended recipient only. If you are not the intended
recipient, you are not authorised to and must not disclose, copy,
distribute, or retain this message or any part of it. It may contain
information which is confidential and/or covered by legal professional
or other privilege. Contracts cannot be concluded with us nor legal
service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United
Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .





Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .


Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast.
s***@public.gmane.org
2010-11-30 23:57:18 UTC
Permalink
Hi David,

Comments in line below.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 30/11/2010, at 10:00 PM, ext Robinson, David wrote:

Hi Sarah,
I should explain that originally my dataset and app did not use textures, instead I apply a colour gradient to the glVertex based on the y value (this I would still like to do in Qt3D but don’t know how?).

Use the addColor*() functions on your QGeometryData before you add it to the builder. There's an example here:

http://qt.gitorious.org/qt-labs/qt3d/blobs/master/examples/pvcolor/pvcolor.cpp#line221

At present we don't have a way to do this from QML.


I only added this in the obj format output because without textures Qt3D crashes when importing the obj & using a shader program to morph, even though the textures are meant to be optional (without them can I still use a shader program?).

Some shaders expect a texture and will cause a crash if its not there - basically if they try to bind an attribute array of texture coordinates that is not there. If you do not have texture coordinates that is fine as long as you use a shader program that does not reference the texture coordinates - such as the QGL::FlatPerVertexColor shader: http://doc.qt.nokia.com/qt3d-snapshot/qgl.html#StandardEffect-enum



As a result I made up some ‘dummy’ textures to go with as an interim, that turns out to be my mistake, thanks for the detailed info, this will be useful to others I’m sure.

Regards
David Robinson
________________________________
From: sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org> [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 30 November 2010 10:54
To: Robinson, David
Cc: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org<mailto:qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org>; ***@nokia.com<mailto:rhys.weatherley-***@public.gmane.org>
Subject: Re: [Qt-3d] Recent developments in Qt/3D

Hi David,

I'm taking some time out to go over this on the list because others might come across the same problem. Event tho' its covered in our doco it can be a bit obtuse to see how it works.

Ok - so there are two problems here -

one is that your file did not have smoothing turned on, and
the second was that specifying texture coordinates (in a way that was unsupported) which was defeating smoothing.

With change c2f154cb67a5c157e7a40f58a40851ed4d6ddd6e you can now specify "ForceSmooth" when loading a model with the obj loader. I have written a few basic unit tests to cover that, and also made some other minor fixes to the loader so it generates node naming a bit more in line with our usage.

But the obj loader was working to spec - albeit perhaps a not very well documented spec.

See this doco:

http://doc.qt.nokia.com/qt3d-snapshot/qglbuilder.html#geometry-data-in-a-section

Here is what happens with smoothing. Say you have a mesh which is a set of row apon row of quad faces - basically a surface divided up into a grid of square faces. This is like your wave obj models. This sort of thing is very common in character modelling and many other types of models too.

In this sort of mesh, each vert is often shared by 6 faces. When you add a quad face, two of the verts are duplicated right away when you divide the quad into two triangles. But there are also duplicates from the neighbouring strips. The loader has to go back through previously added vertices and check to index those, thus storing only one copy of the vert.

Smoothing impacts on this because it is done by taking the normals for each face and averaging it across the mesh - this is done by accumulating each incoming normal at a vertex into a sum, and the renormalizing at the end.

When the mesh is unsmoothed, each different normal at a vertex forces the vertex to retain a copy so it can carry the extra normal information.

To handle this, and to allow smooth shading of these sorts of meshes, here is what happens:

1) Model sends a quad to the builder - the builder calculates a normal vector for the quad if needed
2) That adds two triangles, which means 6 indices, each having the same normal
3) The builder receives the 6 incoming indexed vertices, one after the other, and for each one, tries to coalesce them
4) It looks at previously received vertices and finds ones that are the same - could be in the same quad or from a neighbouring strip
5) if it finds one it will check if it can coalesce them - throwing away the incoming copy and just referencing it with an index
6) the check is done by making sure that information would not be lost - if the new vert copy has unique info it cannot be thrown away
7a) if the mesh is being smoothed, then the normals are absorbed into a sum at each vert (and will not disallow the vert from being coalesced)
7b) if the mesh is being faceted, then the verts have to have their copies retained for each different normal
8) if the mesh has texture coordinates and the same vertex has different tex coords on different indices coalescing cannot happen

The last item 8) is the kicker for you - see the link above for the doco about a texture **seam**.

Other loaders for other 3D software do the same thing.

***@bq-macdev1 ~/depot/research/qt3d: grep '^f ' tests/auto/threed/load_model/models/wave.obj | wc -l
216
***@bq-macdev1 ~/depot/research/qt3d: grep '^v ' tests/auto/threed/load_model/models/wave.obj | wc -l
259

The face commands are quads - with 4 indices.

What this meant was that you got 6 * 216 = 1296 indices. When you had faceted on every face got a different normal and you got 1296 vertices as well.

The next problem was the middle of the file looked like this:

v 180 60 104.229
v 180 120 39.241
v 180 180 20.21
vt 1 0
vt 1 1
vt 0 0
vt 0 1
f 1/1 2/2 9/3 8/4
f 2/1 3/2 10/3 9/4
f 3/1 4/2 11/3 10/4

Here you specify just 4 texture coordinates and map the same ones onto every vertex of the faces. Unfortunately the obj loader does not support texture coordinates like this - so for the last face listed above it would do

f 3/3 4/4 11/11 10/10

What this meant was that you then got every face being unique, so 4 * 216 = 864 vertices.

If you remove those four lines (which didn't seem to get used anyway as you have no materials specified) then you get just 259 vertices. This is at least according to my tests.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 30/11/2010, at 12:03 AM, ext Robinson, David wrote:


Hi Sarah,
Thanks for you help, I wasn’t aware that the obj format I had used which only included vertices & textures (but no normals) would imply such normal characteristics, my mistake.

With the surface smoothing (‘s on’), I now consistently get 864 vertices on the quad face obj. While that appears to improve matters I can still see duplicate vertices in the mesh output. I’m guessing this is made up of (37 x 7 x 3) + ‘Edge effects’ (37 + 37 + 7 + 7 – 1).

I can understand the boundaries as some normal data is needed to constrain the surface here but I don’t know why I still get 3 duplicates for each vert. Does this make sense to you?

Regards
David Robinson
________________________________
From: sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org> [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 29 November 2010 08:39
To: Robinson, David
Cc: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org<mailto:qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org>; ***@nokia.com<mailto:rhys.weatherley-***@public.gmane.org>
Subject: Re: [Qt-3d] Recent developments in Qt/3D

Hi David,

I have not tried to apply your changes - the structure of the repo has changed a bit just recently.

However my investigations so far point to the problem being that your meshes do not specify smoothing to be turned on.

What this means is that the loader will dup the vertex for every normal incident at the vert, so as to give it the faceted appearance.

Try adding "s on" just before the list of faces.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>





On 26/11/2010, at 8:25 PM, ext Robinson, David wrote:



Hi Sarah,
Have you had a chance to look into this duplicate vertex problem with obj file imports?
If necessary, were you able to build the source modifications I provided?

Regards
David Robinson
________________________________
From: Robinson, David
Sent: 17 November 2010 20:14
To: 'sarah.j.smith-***@public.gmane.org<mailto:'sarah.j.smith-***@public.gmane.org>'
Cc: rhys.weatherley-***@public.gmane.org<mailto:rhys.weatherley-***@public.gmane.org>
Subject: RE: [Qt-3d] Recent developments in Qt/3D

Hi Sarah,
Please find attached some vertex output from the MorphItem Qml class run using the 37 x 7 dataset sequence mentioned in my previous email. I think I’ve attached all the bits needed including some experimental Qml. If the mesh import of obj files is where the vertex duplication arises you won’t need to run the qml at all but if you do I’d be interested in your feedback.

The vertex text files can be compared using a text diff utility & it can be seen that there are many duplicate vertices in the internal mesh QGeometryData vertices array for each mesh created from the obj file import, also attached.

This is perhaps more expensive on storage than necessary but itself does not lead to mismatched vertex mapping when morphing. What does is the duplicate vertex no. 363 in the example vertex1296.txt file. Whenever there are 1296 vertices in the data, which occurs in all sequences bar 1 with 1295, it is this vertex no. 363 that is duplicated.

I should also explain that I have tried this with obj files made up of Quad & Triangle faces. I originally used quads as this was more natural for a grid vertex structure. I was thinking that the whole face was being mapped into the vertex array. Eg 37 x 7 x cyclic vertices per face (5) = 1295. When the same no. comes out from using triangle faces my theory is blown over however (37 x 7x 4 x 2 = 2072).

So even when triangle faces are used in the obj’s the vertex count comes out 5 times higher than expected with duplicate adjacent vertices in the array. Can you please investigate the obj scene format plugin and tell me if this is a bug or a lack of understanding on my part, many thanks.

Regards
David Robinson
________________________________
From: sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org> [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 14 November 2010 23:58
To: Robinson, David
Cc: rhys.weatherley-***@public.gmane.org<mailto:rhys.weatherley-***@public.gmane.org>; qt-***@trolltech.com<mailto:qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org>
Subject: Re: [Qt-3d] Recent developments in Qt/3D

Hi David,

That sounds a bit wacky indeed.

Can you send us the code and your .obj files? If this is a bug its a bad one and I should get onto fixing it straight away.

We should not be seeing a lot of extra vertices.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 12/11/2010, at 8:49 PM, ext Robinson, David wrote:

Hi Sarah / Rhys,
As you know I’m writing a MorphItem3D QML class for Qt3D to allow simple surfaces & shapes to transform using a ShaderProgram element. This component is working but I’m finding that the strict one to one mapping of vertices required is broken.

For example I have a simple sequence of mesh grids made up of 37 x 7 (259) data points. I export these to obj files which are imported into Qt3D meshes. When I output the QGeometryData vertices (as an attribute) I find not 259 but 1296 vertices have been created!

Where are all these additional vertices coming from?

Then in the animation sequence I try to morph first to one mesh then another etc. Some meshes have 1296 & some 1294 vertices for example. This breaks the strict mapping required to mix the vertices in the ShaderProgram. If I increase the dataset this mismatch gets worse.

My intention here is to show a varying 3D dataset on a timeline. I am not comfortable with vertex interpolation that is beyond the original dataset particularly when I have no control over it. Is there any way to control the creation of these additional vertices (stick explicitly to the defined data set) or can I govern the mesh to at least use the same number in each?

Regards
David Robinson



Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.


Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.


Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.
Robinson, David
2010-11-30 14:15:33 UTC
Permalink
Hi Sarah,

To confirm, even in my recent repo, untextured mesh imports have the
correct number of vertices. However morphing using a shader program
crashes qmlviewer in: glDrawElements called from:



Qt3Dd.dll!QGLPainter::draw(QGL::DrawingMode mode=Triangles, const
QGLIndexBuffer & indexes={...}, int offset=0, int count=31104) Line 767


Qt3Dd.dll!QGeometryData::draw(QGLPainter * painter=0x0013b3d0, int
start=0, int count=31104, unsigned int mode=4) Line 875

Qt3Dd.dll!QGLSceneNode::drawGeometry(QGLPainter * painter=0x0013b3d0)
Line 1253



I can add a texture even when there are no texcoords but a patchy
surface full of holes is drawn. So I still need to create textures even
though I don't really use them. How should I do this sensibly on a quad
grid & avoid 'unique faces'?



Regards

David Robinson

________________________________

From: Robinson, David
Sent: 30 November 2010 12:01
To: 'sarah.j.smith-***@public.gmane.org'
Cc: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org; rhys.weatherley-***@public.gmane.org
Subject: RE: [Qt-3d] Recent developments in Qt/3D



Hi Sarah,

I should explain that originally my dataset and app did not use
textures, instead I apply a colour gradient to the glVertex based on the
y value (this I would still like to do in Qt3D but don't know how?).



I only added this in the obj format output because without textures Qt3D
crashes when importing the obj & using a shader program to morph, even
though the textures are meant to be optional (without them can I still
use a shader program?).



As a result I made up some 'dummy' textures to go with as an interim,
that turns out to be my mistake, thanks for the detailed info, this will
be useful to others I'm sure.



Regards

David Robinson

________________________________

From: sarah.j.smith-***@public.gmane.org [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 30 November 2010 10:54
To: Robinson, David
Cc: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org; rhys.weatherley-***@public.gmane.org
Subject: Re: [Qt-3d] Recent developments in Qt/3D



Hi David,



I'm taking some time out to go over this on the list because others
might come across the same problem. Event tho' its covered in our doco
it can be a bit obtuse to see how it works.



Ok - so there are two problems here -



one is that your file did not have smoothing turned on, and

the second was that specifying texture coordinates (in a way that
was unsupported) which was defeating smoothing.



With change c2f154cb67a5c157e7a40f58a40851ed4d6ddd6e you can now specify
"ForceSmooth" when loading a model with the obj loader. I have written
a few basic unit tests to cover that, and also made some other minor
fixes to the loader so it generates node naming a bit more in line with
our usage.



But the obj loader was working to spec - albeit perhaps a not very well
documented spec.



See this doco:



http://doc.qt.nokia.com/qt3d-snapshot/qglbuilder.html#geometry-data-in-a
-section



Here is what happens with smoothing. Say you have a mesh which is a set
of row apon row of quad faces - basically a surface divided up into a
grid of square faces. This is like your wave obj models. This sort of
thing is very common in character modelling and many other types of
models too.



In this sort of mesh, each vert is often shared by 6 faces. When you
add a quad face, two of the verts are duplicated right away when you
divide the quad into two triangles. But there are also duplicates from
the neighbouring strips. The loader has to go back through previously
added vertices and check to index those, thus storing only one copy of
the vert.



Smoothing impacts on this because it is done by taking the normals for
each face and averaging it across the mesh - this is done by
accumulating each incoming normal at a vertex into a sum, and the
renormalizing at the end.



When the mesh is unsmoothed, each different normal at a vertex forces
the vertex to retain a copy so it can carry the extra normal
information.



To handle this, and to allow smooth shading of these sorts of meshes,
here is what happens:



1) Model sends a quad to the builder - the builder calculates a normal
vector for the quad if needed

2) That adds two triangles, which means 6 indices, each having the same
normal

3) The builder receives the 6 incoming indexed vertices, one after the
other, and for each one, tries to coalesce them

4) It looks at previously received vertices and finds ones that are the
same - could be in the same quad or from a neighbouring strip

5) if it finds one it will check if it can coalesce them - throwing away
the incoming copy and just referencing it with an index

6) the check is done by making sure that information would not be lost -
if the new vert copy has unique info it cannot be thrown away

7a) if the mesh is being smoothed, then the normals are absorbed into a
sum at each vert (and will not disallow the vert from being coalesced)

7b) if the mesh is being faceted, then the verts have to have their
copies retained for each different normal

8) if the mesh has texture coordinates and the same vertex has different
tex coords on different indices coalescing cannot happen



The last item 8) is the kicker for you - see the link above for the doco
about a texture **seam**.



Other loaders for other 3D software do the same thing.



***@bq-macdev1 ~/depot/research/qt3d: grep '^f '
tests/auto/threed/load_model/models/wave.obj | wc -l

216

***@bq-macdev1 ~/depot/research/qt3d: grep '^v '
tests/auto/threed/load_model/models/wave.obj | wc -l

259



The face commands are quads - with 4 indices.



What this meant was that you got 6 * 216 = 1296 indices. When you had
faceted on every face got a different normal and you got 1296 vertices
as well.



The next problem was the middle of the file looked like this:



v 180 60 104.229

v 180 120 39.241

v 180 180 20.21

vt 1 0

vt 1 1

vt 0 0

vt 0 1

f 1/1 2/2 9/3 8/4

f 2/1 3/2 10/3 9/4

f 3/1 4/2 11/3 10/4



Here you specify just 4 texture coordinates and map the same ones onto
every vertex of the faces. Unfortunately the obj loader does not
support texture coordinates like this - so for the last face listed
above it would do



f 3/3 4/4 11/11 10/10



What this meant was that you then got every face being unique, so 4 *
216 = 864 vertices.



If you remove those four lines (which didn't seem to get used anyway as
you have no materials specified) then you get just 259 vertices. This
is at least according to my tests.



Sarah Smith

Senior Engineer

Nokia Qt Development Frameworks

Mobile: +61 448 283 476

sarah.j.smith-***@public.gmane.org







On 30/11/2010, at 12:03 AM, ext Robinson, David wrote:



Hi Sarah,

Thanks for you help, I wasn't aware that the obj format I had used which
only included vertices & textures (but no normals) would imply such
normal characteristics, my mistake.



With the surface smoothing ('s on'), I now consistently get 864 vertices
on the quad face obj. While that appears to improve matters I can still
see duplicate vertices in the mesh output. I'm guessing this is made up
of (37 x 7 x 3) + 'Edge effects' (37 + 37 + 7 + 7 - 1).



I can understand the boundaries as some normal data is needed to
constrain the surface here but I don't know why I still get 3 duplicates
for each vert. Does this make sense to you?



Regards

David Robinson

________________________________

From: sarah.j.smith-***@public.gmane.org [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 29 November 2010 08:39
To: Robinson, David
Cc: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org; rhys.weatherley-***@public.gmane.org
Subject: Re: [Qt-3d] Recent developments in Qt/3D



Hi David,



I have not tried to apply your changes - the structure of the repo has
changed a bit just recently.



However my investigations so far point to the problem being that your
meshes do not specify smoothing to be turned on.



What this means is that the loader will dup the vertex for every normal
incident at the vert, so as to give it the faceted appearance.



Try adding "s on" just before the list of faces.



Sarah Smith

Senior Engineer

Nokia Qt Development Frameworks

Mobile: +61 448 283 476

sarah.j.smith-***@public.gmane.org









On 26/11/2010, at 8:25 PM, ext Robinson, David wrote:





Hi Sarah,

Have you had a chance to look into this duplicate vertex problem with
obj file imports?

If necessary, were you able to build the source modifications I
provided?



Regards

David Robinson

________________________________

From: Robinson, David
Sent: 17 November 2010 20:14
To: 'sarah.j.smith-***@public.gmane.org'
Cc: rhys.weatherley-***@public.gmane.org
Subject: RE: [Qt-3d] Recent developments in Qt/3D



Hi Sarah,

Please find attached some vertex output from the MorphItem Qml class run
using the 37 x 7 dataset sequence mentioned in my previous email. I
think I've attached all the bits needed including some experimental Qml.
If the mesh import of obj files is where the vertex duplication arises
you won't need to run the qml at all but if you do I'd be interested in
your feedback.



The vertex text files can be compared using a text diff utility & it can
be seen that there are many duplicate vertices in the internal mesh
QGeometryData vertices array for each mesh created from the obj file
import, also attached.



This is perhaps more expensive on storage than necessary but itself does
not lead to mismatched vertex mapping when morphing. What does is the
duplicate vertex no. 363 in the example vertex1296.txt file. Whenever
there are 1296 vertices in the data, which occurs in all sequences bar 1
with 1295, it is this vertex no. 363 that is duplicated.



I should also explain that I have tried this with obj files made up of
Quad & Triangle faces. I originally used quads as this was more natural
for a grid vertex structure. I was thinking that the whole face was
being mapped into the vertex array. Eg 37 x 7 x cyclic vertices per face
(5) = 1295. When the same no. comes out from using triangle faces my
theory is blown over however (37 x 7x 4 x 2 = 2072).



So even when triangle faces are used in the obj's the vertex count comes
out 5 times higher than expected with duplicate adjacent vertices in the
array. Can you please investigate the obj scene format plugin and tell
me if this is a bug or a lack of understanding on my part, many thanks.



Regards

David Robinson

________________________________

From: sarah.j.smith-***@public.gmane.org [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 14 November 2010 23:58
To: Robinson, David
Cc: rhys.weatherley-***@public.gmane.org; qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
Subject: Re: [Qt-3d] Recent developments in Qt/3D



Hi David,



That sounds a bit wacky indeed.



Can you send us the code and your .obj files? If this is a bug its a
bad one and I should get onto fixing it straight away.



We should not be seeing a lot of extra vertices.



Sarah Smith

Senior Engineer

Nokia Qt Development Frameworks

Mobile: +61 448 283 476

sarah.j.smith-***@public.gmane.org







On 12/11/2010, at 8:49 PM, ext Robinson, David wrote:



Hi Sarah / Rhys,

As you know I'm writing a MorphItem3D QML class for Qt3D to allow simple
surfaces & shapes to transform using a ShaderProgram element. This
component is working but I'm finding that the strict one to one mapping
of vertices required is broken.



For example I have a simple sequence of mesh grids made up of 37 x 7
(259) data points. I export these to obj files which are imported into
Qt3D meshes. When I output the QGeometryData vertices (as an attribute)
I find not 259 but 1296 vertices have been created!



Where are all these additional vertices coming from?



Then in the animation sequence I try to morph first to one mesh then
another etc. Some meshes have 1296 & some 1294 vertices for example.
This breaks the strict mapping required to mix the vertices in the
ShaderProgram. If I increase the dataset this mismatch gets worse.



My intention here is to show a varying 3D dataset on a timeline. I am
not comfortable with vertex interpolation that is beyond the original
dataset particularly when I have no control over it. Is there any way to
control the creation of these additional vertices (stick explicitly to
the defined data set) or can I govern the mesh to at least use the same
number in each?



Regards

David Robinson





Please refer to www.anite.com <http://www.anite.com/> for individual
Anite company details. The contents of this e-mail and any attachments
are for the intended recipient only. If you are not the intended
recipient, you are not authorised to and must not disclose, copy,
distribute, or retain this message or any part of it. It may contain
information which is confidential and/or covered by legal professional
or other privilege. Contracts cannot be concluded with us nor legal
service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United
Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .





Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .



Please refer to www.anite.com <http://www.anite.com/> for individual
Anite company details. The contents of this e-mail and any attachments
are for the intended recipient only. If you are not the intended
recipient, you are not authorised to and must not disclose, copy,
distribute, or retain this message or any part of it. It may contain
information which is confidential and/or covered by legal professional
or other privilege. Contracts cannot be concluded with us nor legal
service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United
Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .





Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .



Please refer to www.anite.com <http://www.anite.com/> for individual
Anite company details. The contents of this e-mail and any attachments
are for the intended recipient only. If you are not the intended
recipient, you are not authorised to and must not disclose, copy,
distribute, or retain this message or any part of it. It may contain
information which is confidential and/or covered by legal professional
or other privilege. Contracts cannot be concluded with us nor legal
service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United
Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .





Scanned for viruses by Mimecast <http://www.mimecast.co.uk/> .


Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast.
s***@public.gmane.org
2010-12-01 00:28:26 UTC
Permalink
Hi David,

Comments in line below regarding model issues - Julian and Rhys can probably comment on the shader related crashes better than I can.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 01/12/2010, at 12:15 AM, ext Robinson, David wrote:

Hi Sarah,
To confirm, even in my recent repo, untextured mesh imports have the correct number of vertices. However morphing using a shader program crashes qmlviewer in: glDrawElements called from:

Qt3Dd.dll!QGLPainter::draw(QGL::DrawingMode mode=Triangles, const QGLIndexBuffer & indexes={...}, int offset=0, int count=31104) Line 767
Qt3Dd.dll!QGeometryData::draw(QGLPainter * painter=0x0013b3d0, int start=0, int count=31104, unsigned int mode=4) Line 875
Qt3Dd.dll!QGLSceneNode::drawGeometry(QGLPainter * painter=0x0013b3d0) Line 1253

I wonder if this is because the shader program is trying to bind texture coordinates which are not there - we have copped this one ourselves a few times so I think its fairly likely this is the problem.

Basically inside QGLAbstractEffect::setActive() for texture enabled shaders there is a call to bind those texture coordinates:

http://qt.gitorious.org/qt-labs/qt3d/blobs/master/src/threed/effects/qglflattextureeffect.cpp#line180

Whereas in shaders that don't use texture coordinates there is no such call:

http://qt.gitorious.org/qt-labs/qt3d/blobs/master/src/threed/effects/qglflatcoloreffect.cpp#line154

What's annoying is that this call won't fail - but instead you get a crash deep in the gl stack. Again I'm not sure if I have the details of this 100% correct - Julian and Rhys can probably comment on this better than I can.



I can add a texture even when there are no texcoords but a patchy surface full of holes is drawn. So I still need to create textures even though I don’t really use them. How should I do this sensibly on a quad grid & avoid ‘unique faces’?




If you can't locate the source of the crash using the above tips, and have to resort to the work around of creating fake texture coordinates there is a problem because of the lack of support in the obj loader right now.

http://qt.gitorious.org/qt-labs/qt3d/blobs/master/src/plugins/sceneformats/obj/qglobjscenehandler.cpp#line214

Fancy texture coordinates don't work too well. :-(

In theory what you would need in order to avoid 'unique faces' is to ensure that each time a vertex appears it has the same texture coordinates.

So for example here is a snippet from your obj file - the first few faces:

f 1/1 2/2 9/3 8/4
f 2/1 3/2 10/3 9/4
f 3/1 4/2 11/3 10/4

See how for example vertex 2 is referenced in the first line as having texture coordinate 2, but then it appears in the second line with texture coordinate 1 - that means two copies of vertex 2 have to be created to carry the "seam" information.

What this obj data is saying is that when vertex 2 appears as part of face 1, it has texture coordinate A and when it appears as part of face 2 it has texture coordinate B --> bingo, you have a double up.

Being a text format, obj is good for small files, basic shapes, tests and so on. Since its interpreted and generated in such wildly varying ways its not great for larger projects.

I suspect there might be other problems with our loader, and I would not be surprised that even if this was fixed another problem came up. At present its not really meant for heavy duty use, and our test coverage on loaders is not great.

We are in the middle of working to get the Asset Importer library into Qt3D - this is a nice project that will give us support for Collada (.dae files - like from SketchUp and other programs), as well as .obj, 3ds and others. I have met the guys from Germany who are behind Asset Importer and we've been talking about getting patches upstream - altogether this should be win-win.

Ideally we can get it in for our release.

Once that is done we will likely pension off our existing loaders - keep them around with a compile time switch for compatibility perhaps - but as a result its not something we want to spend time digging to find problems.


Regards
David Robinson
________________________________
From: Robinson, David
Sent: 30 November 2010 12:01
To: 'sarah.j.smith-***@public.gmane.org<mailto:'sarah.j.smith-***@public.gmane.org>'
Cc: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org<mailto:qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org>; ***@nokia.com<mailto:rhys.weatherley-***@public.gmane.org>
Subject: RE: [Qt-3d] Recent developments in Qt/3D

Hi Sarah,
I should explain that originally my dataset and app did not use textures, instead I apply a colour gradient to the glVertex based on the y value (this I would still like to do in Qt3D but don’t know how?).

I only added this in the obj format output because without textures Qt3D crashes when importing the obj & using a shader program to morph, even though the textures are meant to be optional (without them can I still use a shader program?).

As a result I made up some ‘dummy’ textures to go with as an interim, that turns out to be my mistake, thanks for the detailed info, this will be useful to others I’m sure.

Regards
David Robinson
________________________________
From: sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org> [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 30 November 2010 10:54
To: Robinson, David
Cc: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org<mailto:qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org>; ***@nokia.com<mailto:rhys.weatherley-***@public.gmane.org>
Subject: Re: [Qt-3d] Recent developments in Qt/3D

Hi David,

I'm taking some time out to go over this on the list because others might come across the same problem. Event tho' its covered in our doco it can be a bit obtuse to see how it works.

Ok - so there are two problems here -

one is that your file did not have smoothing turned on, and
the second was that specifying texture coordinates (in a way that was unsupported) which was defeating smoothing.

With change c2f154cb67a5c157e7a40f58a40851ed4d6ddd6e you can now specify "ForceSmooth" when loading a model with the obj loader. I have written a few basic unit tests to cover that, and also made some other minor fixes to the loader so it generates node naming a bit more in line with our usage.

But the obj loader was working to spec - albeit perhaps a not very well documented spec.

See this doco:

http://doc.qt.nokia.com/qt3d-snapshot/qglbuilder.html#geometry-data-in-a-section

Here is what happens with smoothing. Say you have a mesh which is a set of row apon row of quad faces - basically a surface divided up into a grid of square faces. This is like your wave obj models. This sort of thing is very common in character modelling and many other types of models too.

In this sort of mesh, each vert is often shared by 6 faces. When you add a quad face, two of the verts are duplicated right away when you divide the quad into two triangles. But there are also duplicates from the neighbouring strips. The loader has to go back through previously added vertices and check to index those, thus storing only one copy of the vert.

Smoothing impacts on this because it is done by taking the normals for each face and averaging it across the mesh - this is done by accumulating each incoming normal at a vertex into a sum, and the renormalizing at the end.

When the mesh is unsmoothed, each different normal at a vertex forces the vertex to retain a copy so it can carry the extra normal information.

To handle this, and to allow smooth shading of these sorts of meshes, here is what happens:

1) Model sends a quad to the builder - the builder calculates a normal vector for the quad if needed
2) That adds two triangles, which means 6 indices, each having the same normal
3) The builder receives the 6 incoming indexed vertices, one after the other, and for each one, tries to coalesce them
4) It looks at previously received vertices and finds ones that are the same - could be in the same quad or from a neighbouring strip
5) if it finds one it will check if it can coalesce them - throwing away the incoming copy and just referencing it with an index
6) the check is done by making sure that information would not be lost - if the new vert copy has unique info it cannot be thrown away
7a) if the mesh is being smoothed, then the normals are absorbed into a sum at each vert (and will not disallow the vert from being coalesced)
7b) if the mesh is being faceted, then the verts have to have their copies retained for each different normal
8) if the mesh has texture coordinates and the same vertex has different tex coords on different indices coalescing cannot happen

The last item 8) is the kicker for you - see the link above for the doco about a texture **seam**.

Other loaders for other 3D software do the same thing.

***@bq-macdev1 ~/depot/research/qt3d: grep '^f ' tests/auto/threed/load_model/models/wave.obj | wc -l
216
***@bq-macdev1 ~/depot/research/qt3d: grep '^v ' tests/auto/threed/load_model/models/wave.obj | wc -l
259

The face commands are quads - with 4 indices.

What this meant was that you got 6 * 216 = 1296 indices. When you had faceted on every face got a different normal and you got 1296 vertices as well.

The next problem was the middle of the file looked like this:

v 180 60 104.229
v 180 120 39.241
v 180 180 20.21
vt 1 0
vt 1 1
vt 0 0
vt 0 1
f 1/1 2/2 9/3 8/4
f 2/1 3/2 10/3 9/4
f 3/1 4/2 11/3 10/4

Here you specify just 4 texture coordinates and map the same ones onto every vertex of the faces. Unfortunately the obj loader does not support texture coordinates like this - so for the last face listed above it would do

f 3/3 4/4 11/11 10/10

What this meant was that you then got every face being unique, so 4 * 216 = 864 vertices.

If you remove those four lines (which didn't seem to get used anyway as you have no materials specified) then you get just 259 vertices. This is at least according to my tests.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 30/11/2010, at 12:03 AM, ext Robinson, David wrote:

Hi Sarah,
Thanks for you help, I wasn’t aware that the obj format I had used which only included vertices & textures (but no normals) would imply such normal characteristics, my mistake.

With the surface smoothing (‘s on’), I now consistently get 864 vertices on the quad face obj. While that appears to improve matters I can still see duplicate vertices in the mesh output. I’m guessing this is made up of (37 x 7 x 3) + ‘Edge effects’ (37 + 37 + 7 + 7 – 1).

I can understand the boundaries as some normal data is needed to constrain the surface here but I don’t know why I still get 3 duplicates for each vert. Does this make sense to you?

Regards
David Robinson
________________________________
From: sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org> [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 29 November 2010 08:39
To: Robinson, David
Cc: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org<mailto:qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org>; ***@nokia.com<mailto:rhys.weatherley-***@public.gmane.org>
Subject: Re: [Qt-3d] Recent developments in Qt/3D

Hi David,

I have not tried to apply your changes - the structure of the repo has changed a bit just recently.

However my investigations so far point to the problem being that your meshes do not specify smoothing to be turned on.

What this means is that the loader will dup the vertex for every normal incident at the vert, so as to give it the faceted appearance.

Try adding "s on" just before the list of faces.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>




On 26/11/2010, at 8:25 PM, ext Robinson, David wrote:


Hi Sarah,
Have you had a chance to look into this duplicate vertex problem with obj file imports?
If necessary, were you able to build the source modifications I provided?

Regards
David Robinson
________________________________
From: Robinson, David
Sent: 17 November 2010 20:14
To: 'sarah.j.smith-***@public.gmane.org<mailto:'sarah.j.smith-***@public.gmane.org>'
Cc: rhys.weatherley-***@public.gmane.org<mailto:rhys.weatherley-***@public.gmane.org>
Subject: RE: [Qt-3d] Recent developments in Qt/3D

Hi Sarah,
Please find attached some vertex output from the MorphItem Qml class run using the 37 x 7 dataset sequence mentioned in my previous email. I think I’ve attached all the bits needed including some experimental Qml. If the mesh import of obj files is where the vertex duplication arises you won’t need to run the qml at all but if you do I’d be interested in your feedback.

The vertex text files can be compared using a text diff utility & it can be seen that there are many duplicate vertices in the internal mesh QGeometryData vertices array for each mesh created from the obj file import, also attached.

This is perhaps more expensive on storage than necessary but itself does not lead to mismatched vertex mapping when morphing. What does is the duplicate vertex no. 363 in the example vertex1296.txt file. Whenever there are 1296 vertices in the data, which occurs in all sequences bar 1 with 1295, it is this vertex no. 363 that is duplicated.

I should also explain that I have tried this with obj files made up of Quad & Triangle faces. I originally used quads as this was more natural for a grid vertex structure. I was thinking that the whole face was being mapped into the vertex array. Eg 37 x 7 x cyclic vertices per face (5) = 1295. When the same no. comes out from using triangle faces my theory is blown over however (37 x 7x 4 x 2 = 2072).

So even when triangle faces are used in the obj’s the vertex count comes out 5 times higher than expected with duplicate adjacent vertices in the array. Can you please investigate the obj scene format plugin and tell me if this is a bug or a lack of understanding on my part, many thanks.

Regards
David Robinson
________________________________
From: sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org> [mailto:sarah.j.smith-***@public.gmane.org]
Sent: 14 November 2010 23:58
To: Robinson, David
Cc: rhys.weatherley-***@public.gmane.org<mailto:rhys.weatherley-***@public.gmane.org>; qt-***@trolltech.com<mailto:qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org>
Subject: Re: [Qt-3d] Recent developments in Qt/3D

Hi David,

That sounds a bit wacky indeed.

Can you send us the code and your .obj files? If this is a bug its a bad one and I should get onto fixing it straight away.

We should not be seeing a lot of extra vertices.

Sarah Smith
Senior Engineer
Nokia Qt Development Frameworks
Mobile: +61 448 283 476
sarah.j.smith-***@public.gmane.org<mailto:sarah.j.smith-***@public.gmane.org>



On 12/11/2010, at 8:49 PM, ext Robinson, David wrote:

Hi Sarah / Rhys,
As you know I’m writing a MorphItem3D QML class for Qt3D to allow simple surfaces & shapes to transform using a ShaderProgram element. This component is working but I’m finding that the strict one to one mapping of vertices required is broken.

For example I have a simple sequence of mesh grids made up of 37 x 7 (259) data points. I export these to obj files which are imported into Qt3D meshes. When I output the QGeometryData vertices (as an attribute) I find not 259 but 1296 vertices have been created!

Where are all these additional vertices coming from?

Then in the animation sequence I try to morph first to one mesh then another etc. Some meshes have 1296 & some 1294 vertices for example. This breaks the strict mapping required to mix the vertices in the ShaderProgram. If I increase the dataset this mismatch gets worse.

My intention here is to show a varying 3D dataset on a timeline. I am not comfortable with vertex interpolation that is beyond the original dataset particularly when I have no control over it. Is there any way to control the creation of these additional vertices (stick explicitly to the defined data set) or can I govern the mesh to at least use the same number in each?

Regards
David Robinson



Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.


Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.


Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.



Please refer to www.anite.com<http://www.anite.com/> for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast<http://www.mimecast.co.uk/>.
Rhys Weatherley
2010-11-01 21:51:11 UTC
Permalink
On Monday 01 November 2010, ext Robinson, David wrote:
> Hi Rhys,
> Regarding the Viewport & qmlviewer vs qml3d. I still cannot get explicit
> MouseAreas to work with qmlviewer when I'm using a viewport.
>
> This makes it really hard to mix 2D & 3D qml. Have you go a working
> qmlviewer based example?

The teapot-shader-images.qml example has a MouseArea attached to a Viewport -
clicking anywhere in the window will change the texture on the teapot.

> Also even when my 2D element has a z: stacking order the Viewport is
> drawn over the top. Is there any way to control this?

Can you give me a QML example of what you are trying to do?

> When recording frames using 'qmlviewer' the viewport is not captured, so
> an empty image sequence is generated.

The record function in qmlviewer doesn't work with OpenGL because OpenGL
cannot be used to render into a QImage for the capture mechanism. Sorry.

Cheers,

Rhys.
Robinson, David
2010-11-03 12:31:52 UTC
Permalink
Hi Rhys,
For MouseAreas my Qml structure was wrong. I now have something that
works based on the following top level:
Item {
Rectangle { //2D Qml elements
Toolbar {
Button {
}
}
}
Viewport { //3D Qml elements
Item3D {
}
ShaderProgram {
}
}
}
Thanks for the pointers.

Regarding qmlviewer frame recording and compilation with ffmpeg. This is
only a limitation of the current implementation isn't it?

I use ffmpeg with OpenGL to create movies like the one I sent. All you
need do is paint a QPixmap instead of a QImage using:

QPixmap pic = QPixmap::grabWidget(this); on a QWidget
OR
QPixmap pic = QGLWidget::renderPixmap(w, h, useContext); on a QGLWidget

And then save using: pic.toImage()

As part of the Qt3D integration with qmlviewer I think we need something
like this. I can send you the code I use to do this if the Qt3D team can
be persuaded to pursue it.

Regards
David Robinson


-----Original Message-----
From: qt-3d-bounces-Ihz76zOu8S21Z/+***@public.gmane.org [mailto:qt-3d-bounces-Ihz76zOu8S21Z/+***@public.gmane.org]
On Behalf Of Rhys Weatherley
Sent: 01 November 2010 21:51
To: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
Subject: Re: [Qt-3d] Recent developments in Qt/3D

On Monday 01 November 2010, ext Robinson, David wrote:
> Hi Rhys,
> Regarding the Viewport & qmlviewer vs qml3d. I still cannot get
explicit
> MouseAreas to work with qmlviewer when I'm using a viewport.
>
> This makes it really hard to mix 2D & 3D qml. Have you go a working
> qmlviewer based example?

The teapot-shader-images.qml example has a MouseArea attached to a
Viewport -
clicking anywhere in the window will change the texture on the teapot.

> Also even when my 2D element has a z: stacking order the Viewport is
> drawn over the top. Is there any way to control this?

Can you give me a QML example of what you are trying to do?

> When recording frames using 'qmlviewer' the viewport is not captured,
so
> an empty image sequence is generated.

The record function in qmlviewer doesn't work with OpenGL because OpenGL

cannot be used to render into a QImage for the capture mechanism.
Sorry.

Cheers,

Rhys.
_______________________________________________
Qt-3d mailing list
Qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
http://lists.trolltech.com/mailman/listinfo/qt-3d


Scanned for viruses by Mimecast.


Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast.
r***@public.gmane.org
2010-11-03 18:46:11 UTC
Permalink
I suggest logging a bug for this against the "Declarative" component of Qt, with your suggestion as to how to fix qmlviewer to do this. It looks reasonable, but the DeclarativeUI people will need to look it over to be certain.

Cheers,

Rhys.
________________________________________
From: ext Robinson, David [David.Robinson-***@public.gmane.org]
Sent: Wednesday, November 03, 2010 10:31 PM
To: Weatherley Rhys (Nokia-MS-Qt/Brisbane); qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
Subject: RE: [Qt-3d] Recent developments in Qt/3D

Hi Rhys,
For MouseAreas my Qml structure was wrong. I now have something that
works based on the following top level:
Item {
Rectangle { //2D Qml elements
Toolbar {
Button {
}
}
}
Viewport { //3D Qml elements
Item3D {
}
ShaderProgram {
}
}
}
Thanks for the pointers.

Regarding qmlviewer frame recording and compilation with ffmpeg. This is
only a limitation of the current implementation isn't it?

I use ffmpeg with OpenGL to create movies like the one I sent. All you
need do is paint a QPixmap instead of a QImage using:

QPixmap pic = QPixmap::grabWidget(this); on a QWidget
OR
QPixmap pic = QGLWidget::renderPixmap(w, h, useContext); on a QGLWidget

And then save using: pic.toImage()

As part of the Qt3D integration with qmlviewer I think we need something
like this. I can send you the code I use to do this if the Qt3D team can
be persuaded to pursue it.

Regards
David Robinson


-----Original Message-----
From: qt-3d-bounces-Ihz76zOu8S21Z/+***@public.gmane.org [mailto:qt-3d-bounces-Ihz76zOu8S21Z/+***@public.gmane.org]
On Behalf Of Rhys Weatherley
Sent: 01 November 2010 21:51
To: qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
Subject: Re: [Qt-3d] Recent developments in Qt/3D

On Monday 01 November 2010, ext Robinson, David wrote:
> Hi Rhys,
> Regarding the Viewport & qmlviewer vs qml3d. I still cannot get
explicit
> MouseAreas to work with qmlviewer when I'm using a viewport.
>
> This makes it really hard to mix 2D & 3D qml. Have you go a working
> qmlviewer based example?

The teapot-shader-images.qml example has a MouseArea attached to a
Viewport -
clicking anywhere in the window will change the texture on the teapot.

> Also even when my 2D element has a z: stacking order the Viewport is
> drawn over the top. Is there any way to control this?

Can you give me a QML example of what you are trying to do?

> When recording frames using 'qmlviewer' the viewport is not captured,
so
> an empty image sequence is generated.

The record function in qmlviewer doesn't work with OpenGL because OpenGL

cannot be used to render into a QImage for the capture mechanism.
Sorry.

Cheers,

Rhys.
_______________________________________________
Qt-3d mailing list
Qt-3d-Ihz76zOu8S21Z/+***@public.gmane.org
http://lists.trolltech.com/mailman/listinfo/qt-3d


Scanned for viruses by Mimecast.


Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.

Anite plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom VAT Registration No. GB 787 418187

Scanned for viruses by Mimecast.
Loading...