Re: ocean LOD bug fix -> desired result achieved! r: 38157

res <[email protected]>
Newsgroups gmane.comp.graphics.crystalspace.devel
Message-ID <[email protected]>
On 10.06.2012 22:23, Naman Gupta wrote:
> Namaste,
> 
>    I managed to get desired result for Ocean LOD using multiple
> buffers.  code is very messy but yeah understandable. also optimization
> is remaining.   any comments? 
>  
> i'll work on fixing shaders now. and will fix the code and optimize
> in July as per schedule.  or could be made flexible 

It looks much nicer without those gaps! :)

About the code: well, you think yourself it's a bit messy... so I
recommend you clean it up a bit before proceeding. A good start would be
to bring it into a shape that you would consider “clean” by your own
standards ;)
There's obviously a lot of repetition where the boundary meshes are
concerned. I'd probably try to factor the similar but not quite the same
code blocks into a function and/or loop. (Something simple as merging
the separate …_TL, …_TH members into one array would really make turning
the repeated blocks of code into loops the natural thing to do.)

The generation of the boundary meshes is a bit ...opaque... itself. (But
then, mostly but not quite entirely code with a lot of arithmetic on
indices tends to be so.) Some additional commentary in the code would
really help here. If I gathered it right you used some paper/online
resource as the basis for the boundary mesh logic; it would be really
good to cite this. If the algorithm can be well explained in a graphical
way and you feel fancy, perhaps add some ASCII art.

About optimization: I compared waterdemo2 on trunk and your branch; with
my not-so-blazingly-fast integrated graphics the numbers are ~60fps
(trunk) vs ~30fps (branch) – clearly, there' still potential for
optimization here.
One good reason for approaching this now, instead of later (July), is
that the whole boundary thing is still fresh in your head, which can
help when trying to look at it from different angles.
Personally, I'd like to now how my “brute” approach of having indices
for a whole LOD level for each possible combination of half-res vs
full-res for an edge stacks up against current approach.
Did you have any ideas for optimization while writing the code? If so,
perhaps just “experiment” a bit and see how things perform. If you feel
the time is slipping too much you can still put optimization on the
“todo” list and move on.

-f.r.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
Crystal-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-develop
signature.asc (application/pgp-signature, 262 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/WXckACgkQNCTzcE/07exwHwCdGnfhWJ3juJIHfNpSASUUYEzD
E+cAnick7Hmlvhw1BTGBmmEJyl7sVGKb
=Av7V
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.